MENU

Teams VDIでSlimCore MSIXがHTTP 403／404になる原因とネットワーク診断手順

Teams

Teams VDI 2.0でSlimCore MSIXの取得時にHTTP 403／404が発生した場合、最初に確認すべきなのは仮想マシン側ではなく、利用者が操作している物理端末・シンクライアント側のダウンロード経路です。

HTTP 403は、プロキシ、URLフィルタリング、ファイアウォールなどがSlimCore MSIXの取得を拒否している可能性を優先して調査します。一方、HTTP 404はMicrosoft CDN上に対象パッケージが存在しない配布側の問題を考慮しつつ、プロキシがURLを書き換えたり、独自の404を返したりしていないかも切り分ける必要があります。Microsoftの現行トラブルシューティングでも、403はネットワークまたはプロキシによるブロック、404はCDN上のパッケージ公開問題またはプロキシ干渉の可能性として整理されています。 (Microsoft Learn)

この記事では、Teamsログから403／404を特定する方法、*.office.netへの通信確認、プロキシ経由と直接経路の比較、404をMicrosoft側へエスカレーションする判断基準まで、VDI・ネットワーク管理者向けに解説します。

目次

Teams VDIのSlimCore MSIXで403／404が出た場合の結論

まず、エラーコードごとの調査対象を整理します。

ログ上のコード意味最初に確認する場所
403／3227HTTP_STATUS_FORBIDDENエンドポイント側のプロキシ、URLフィルタ、ファイアウォール
404／3235HTTP_STATUS_NOT_FOUNDCDN上の公開状況、プロキシのキャッシュやURL書き換え
3005／24043MSIXを2分以内にダウンロードできない回線速度、プロキシ遅延、ダウンロード制限
12030Microsoft CDNとの接続が異常終了DNS、TLS、プロキシ、ネットワーク切断
1260／10083MSIXのインストールがポリシーで拒否AppLocker、WDAC、GPO
15615／1951MSIXのインストールポリシーエラーAllowAllTrustedApps、サイドローディング設定

Microsoftの公式資料では、403／404はSlimCore MSIXをMicrosoft CDNから取得する段階で発生するエラーとして扱われています。これに対して、1260や15615はダウンロード後のステージング・登録段階で発生するエラーです。 (Microsoft Learn)

したがって、HTTP 403／404が記録されている段階で、AppLockerやAllowAllTrustedAppsの設定変更から始めるのは適切ではありません。まずダウンロード経路を正常化し、その後にインストールエラーが残る場合だけAppXやGPOを調査します。

なぜ仮想マシンではなくエンドポイント側を調べるのか

Teams VDI 2.0では、仮想マシン上のTeamsがSlimCore MSIXを直接ダウンロードするわけではありません。

Azure Virtual Desktop、Windows 365、Citrix、Omnissa HorizonなどのVDIクライアントに組み込まれたMicrosoft Teams VDIプラグインが、利用者のエンドポイント側でSlimCore MSIXを取得します。SlimCoreはMicrosoftのパブリックCDNで配布され、取得後はエンドポイント上にサイレントで登録されます。 (Microsoft Learn)

通信経路は、概ね次のようになります。

仮想マシン上のTeams
        ↓ 仮想チャネル
Windows App／Citrix Workspace app／Horizon Client
        ↓
エンドポイント上のTeams VDIプラグイン
        ↓
Microsoft CDNからSlimCore MSIXを取得
        ↓
エンドポイント上でMSIXを登録
        ↓
MsTeamsVdi.exeを起動

つまり、VMからMicrosoft CDNへ接続できても、エンドポイントのプロキシやファイアウォールで遮断されていれば403／404は解消しません。

ネットワークログを調べるときも、送信元IPアドレスはVDIホストではなく、原則としてWindows端末やシンクライアントのIPアドレスを確認します。SlimCoreの実行後も、Teamsのシグナリングやメディアに関するネットワーク通信はエンドポイント側のMsTeamsVdi.exeが担当します。 (Microsoft Learn)

TeamsログからHTTP 403／404を確認する

Teamsの診断ログを取得する

仮想マシン上でTeamsを起動した状態で、次のキーを押します。

Ctrl + Alt + Shift + 1

ダウンロードフォルダーに、次のようなZIPファイルが作成されます。

PROD-WebLogs-*.zip

ZIPを展開し、Coreフォルダー内のログを確認します。VDI関連の主要情報はVdi_debug.txtやDiagnostics-logs.txtなどに記録されます。Microsoft公式資料では、loadErrcとdeployErrcを含む行から接続・展開エラーを確認する方法が案内されています。 (Microsoft Learn)

ログをPowerShellで検索する

展開したログフォルダーでPowerShellを開き、次のコマンドを実行します。

Get-ChildItem . -Recurse -File -Include *.txt,*.log,*.json |
    Select-String -Pattern `
        'loadErrc',
        'deployErrc',
        'vdiBridgeEventsHandler',
        '3227',
        '3235',
        'HTTP_STATUS_FORBIDDEN',
        'HTTP_STATUS_NOT_FOUND'

次のような情報を記録します。

  • エラーが発生した日時
  • loadErrcとdeployErrc
  • HTTP 403または404
  • 3227または3235
  • 要求されたSlimCoreのバージョン
  • エンドポイントを識別するnodeId
  • Teams、VDIクライアント、プラグインのバージョン
  • connectedStackがremoteかlocalか

Teamsログに完全なダウンロードURLが記録されていない場合は、同じ時刻のプロキシ、ファイアウォール、EDRのネットワークログから、接続先FQDNとURLパスを特定します。

HTTP 403のネットワーク診断

HTTP 403は、サーバーまたは中継機器がリクエストを理解したものの、処理を拒否した状態です。Teams VDIの公式トラブルシューティングでは、SlimCore MSIXのダウンロードを何らかの要素がブロックしているため、ネットワークおよびプロキシ担当者に確認するよう案内されています。 (Microsoft Learn)

403を返した機器を特定する

最初に確認するのは、403をMicrosoft CDNが返したのか、社内プロキシが返したのかです。

プロキシログやHTTPレスポンスで、次の情報を確認します。

確認項目判断の手掛かり
Response HeaderのServerCDNまたはプロキシ製品を識別できる場合がある
Via、X-Cache、独自ヘッダー中継プロキシやキャッシュを通過している可能性
Response BodyURLフィルタ製品のブロック画面ではないか
プロキシのActionDeny、Block、Policy Rejectなどになっていないか
URLカテゴリMicrosoft CDNが未分類または禁止カテゴリになっていないか
TLS復号ポリシー復号対象と除外対象のどちらになっているか
認証結果非ブラウザ通信でプロキシ認証に失敗していないか

403のレスポンス本文が、Microsoftの応答ではなくプロキシ製品のHTMLブロックページであれば、Microsoft側ではなく社内ネットワーク側の拒否と判断できます。

*.office.netが許可されているか確認する

MicrosoftのTeams VDI 2.0向けネットワーク要件では、Microsoft 365エンドポイントID 47の*.office.netがSlimCoreのダウンロードに使用されます。現在の公式資料では、TCP 443および80が必要なポートとして掲載されています。 (Microsoft Learn)

特に、次のような許可設定では不足する可能性があります。

teams.microsoft.comだけを許可している
*.teams.microsoft.comだけを許可している
Microsoft Teamsのメディア用IPアドレスだけを許可している
特定のoffice.netホスト名を1件だけ許可している

SlimCore MSIXの取得については、少なくとも次の観点を確認します。

接続先: *.office.net
方向: エンドポイントからインターネットへの送信
プロトコル: TCP
ポート: 443、80

Microsoft 365のURLやIPアドレス範囲は更新される可能性があるため、一度取得したIPアドレスを固定で登録するのではなく、公式のMicrosoft 365エンドポイント情報を継続的に反映できる運用が必要です。MicrosoftもTeams VDIのネットワーク要件について、公式一覧を継続監視するよう案内しています。 (Microsoft Learn)

プロキシ設定をエンドポイント側で確認する

まず、WinHTTPの設定を確認します。

netsh winhttp show proxy

次に、サインインユーザーのプロキシとPAC設定を確認します。

Get-ItemProperty `
    'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
    Select-Object ProxyEnable, ProxyServer, AutoConfigURL

環境変数でプロキシが指定されていないかも確認します。

Get-ChildItem Env: |
    Where-Object Name -Match 'HTTP_PROXY|HTTPS_PROXY|NO_PROXY'

ここで注意したいのは、ブラウザーでoffice.netへアクセスできることだけでは、SlimCoreのダウンロード経路が正常とは判断できない点です。

SlimCoreの取得にはBITSが関係するため、ブラウザーとBITSで参照するプロキシ設定、認証方法、実行コンテキストが異なる可能性があります。BITSではユーザーのプロキシ設定だけでなく、ジョブ固有のプロキシ設定や認証情報も扱えるため、最終的にはプロキシ側の実通信ログで判断する必要があります。 (Microsoft Learn)

認証プロキシを使用している場合の注意点

認証プロキシ環境では、ブラウザーが統合Windows認証で通過できても、バックグラウンドプロセスやBITSジョブでは同じ認証が成立しない場合があります。

次の条件を確認します。

  • 非ブラウザ通信でもプロキシ認証が成立するか
  • PACファイルがエンドポイントから取得できるか
  • PAC内の条件分岐が*.office.netを想定しているか
  • DIRECTとPROXYの切り替えが意図どおりか
  • ユーザーごとに異なるプロキシポリシーが適用されていないか
  • シンクライアントのシステム時刻が正しいか
  • プロキシ資格情報の期限切れがないか

403が特定ユーザーだけで発生する場合は、端末単位の許可設定だけでなく、プロキシ認証グループやユーザー別URLフィルタポリシーも確認します。

許可された比較テストを実施する

組織のセキュリティルール上許可される場合は、同じエンドポイントで経路だけを変えて比較します。

テスト結果判断の目安
社内プロキシ経由では403、許可された直接経路では成功プロキシまたは社内ファイアウォールが原因
ある拠点だけ403拠点固有のプロキシ、DNS、出口回線を確認
ある端末だけ403端末側エージェント、PAC、証明書、キャッシュを確認
全端末・全経路で同じURLが403URLの有効性、要求方法、Microsoft側の応答を確認
ブラウザーは成功、Teams VDIだけ403BITS、非ブラウザ認証、実行コンテキストを確認

TLSインスペクションを使用している場合でも、最初から全Microsoft通信を復号除外するのではなく、対象FQDNと対象端末を限定した検証ポリシーで比較します。除外によって成功することを確認してから、必要最小限の恒久設定を設計するのが安全です。

HTTP 404のネットワーク診断

Microsoft公式資料では、HTTP 404／3235を「SlimCore MSIXパッケージがCDN上に見つからない公開問題」と説明しています。現行英語版では、プロキシサーバーによる干渉の可能性も併記されています。 (Microsoft Learn)

そのため、404を見ただけで「Microsoft側の障害」と断定するのも、「社内ファイアウォールの遮断」と断定するのも適切ではありません。

実際に要求されたURLとバージョンを確認する

404では、要求先ホスト名だけでなく、URLパスとパッケージバージョンが重要です。

次の情報をプロキシログやクライアントログから取得します。

接続先FQDN
完全なURLパス
HTTPメソッド
SlimCoreのパッケージ名
要求されたバージョン
HTTPレスポンスコード
レスポンスヘッダー
リダイレクト元とリダイレクト先

外部へログを共有する場合は、URLのクエリパラメーターに一時トークンや識別情報が含まれていないか確認し、必要に応じて値をマスクします。ただし、ホスト名、パス、パッケージ名、バージョンは切り分けに必要なため残します。

プロキシが独自の404を返していないか確認する

プロキシやセキュリティ製品が、ブロック時に必ず403を返すとは限りません。製品やポリシーによっては、接続先を隠すために404を生成する場合があります。

次の処理が行われていないか確認します。

  • URLパスの書き換え
  • クエリ文字列の削除
  • HTTPからHTTPSへのリダイレクト遮断
  • CDNレスポンスの負のキャッシュ
  • 古い404レスポンスのキャッシュ
  • ファイル拡張子によるMSIX遮断
  • ダウンロード先ホストのカテゴリ誤判定
  • リダイレクト先FQDNの許可漏れ

プロキシキャッシュを使用している場合は、対象URLに対して古い404が残っていないか確認します。キャッシュ削除後に成功するのであれば、Microsoft CDNの公開問題ではなく、プロキシ側の負のキャッシュが原因だったと判断できます。

同じURLを異なる経路で比較する

404を切り分ける際は、同じURL、同じパッケージバージョン、同じ時刻帯で比較することが重要です。

結果判断の目安
プロキシ経由だけ404プロキシのキャッシュ、URL書き換え、フィルタリングを疑う
許可された直接経路でも同じ404CDN上の公開状況またはURL自体を疑う
古いVDIイメージだけ404古いTeamsビルドが要求するSlimCoreバージョンを確認
新しいTeamsでは成功、古いTeamsでは404バージョン整合性とサポート要件を確認
拠点や出口回線によって結果が異なるCDN経路または拠点プロキシのキャッシュを確認
時間を置くと同一設定で成功一時的なCDN公開・同期問題の可能性を記録して監視

古いTeamsビルドを使い続けていないか確認する

現在のSlimCoreはHostとFrameworkに分割され、FrameworkパッケージはVM上のTeamsバージョンに対応するものがエンドポイントへ取得されます。Microsoftは互換性のために最大12バージョンのSlimCoreVdi Frameworkを保持すると説明していますが、無期限にすべての旧バージョンが保持されるわけではありません。 (Microsoft Learn)

非永続VDIでTeamsの更新を長期間停止している場合や、古いゴールデンイメージを展開している場合は、次を確認します。

  • VM上のTeamsバージョン
  • Windows App、Citrix Workspace appなどのバージョン
  • Teams VDIプラグインのバージョン
  • 要求されたSlimCore Frameworkのバージョン
  • Microsoftが公開しているサポート対象の最低バージョン

古い環境だけで404になる場合は、ネットワーク設定を繰り返し変更する前に、サポート対象バージョンへの更新を検討します。

エンドポイント側で実行する確認コマンド

DNSとTCP 443を確認する

プロキシログなどから実際のFQDNを特定し、エンドポイントで実行します。

$HostName = "実際に要求されたFQDN"

Resolve-DnsName $HostName
Test-NetConnection $HostName -Port 443

TcpTestSucceeded : Trueは、TCP 443への接続が成立したことを示すだけです。MSIXのURLが許可されていることや、HTTPレスポンスが正常であることまでは証明できません。

実際のURLへHTTPリクエストを送る

完全なURLを取得できた場合は、変更管理とセキュリティルールの範囲内で確認します。

curl.exe -v -L --output NUL "実際に要求された完全なURL"

確認するポイントは次のとおりです。

  • 接続先IPアドレス
  • 使用されたプロキシ
  • TLS証明書の発行先
  • リダイレクトの有無
  • 最終的なHTTPステータス
  • 403／404のレスポンスヘッダー
  • レスポンスを返したサーバー

ただし、curl.exeが成功しても、Teams VDIプラグインやBITSと同じプロキシ・認証コンテキストを完全に再現できるとは限りません。curlによる確認は、DNS、TLS、HTTP応答を調べる補助テストとして使用します。

SlimCore MSIXの登録状況を確認する

エンドポイント側で次のPowerShellを実行します。

Get-AppxPackage Microsoft.Teams.SlimCore* |
    Select-Object Name, Version, Status, PackageFullName, InstallLocation

Microsoftは、アクセス制限されたC:\Program Files\WindowsAppsの所有権を取得して直接確認するのではなく、Get-AppxPackageを使用する方法を案内しています。 (Microsoft Learn)

新しい分割MSIX構成では、主に次のパッケージが表示されます。

Microsoft.Teams.SlimCoreVdiHost.win-x64
Microsoft.Teams.SlimCoreVdiFwk.win-x64.<version>

必要なFrameworkが存在せず、その直前に403／404が記録されている場合は、ダウンロード段階の問題と判断できます。

一方、パッケージが存在してStatus : Okであれば、古いログを見ていないか、別バージョンのFramework取得で失敗していないかを確認します。

ダウンロード成功後に失敗する場合の確認場所

HTTP 403／404が解消した後に、1260、15615、AppX関連のエラーへ変わることがあります。この場合は、ネットワークではなくMSIXのステージング・登録処理へ調査対象を移します。

エンドポイントのイベントビューアーで、次のログを確認します。

アプリケーションとサービス ログ
  └ Microsoft
     └ Windows
        ├ AppxPackagingOM
        │  └ Operational
        └ AppXDeployment-Server
           └ Operational

Microsoftは、SlimCoreVdi MSIXの展開エラーについて、AppxPackagingOMとAppXDeploymentServerのイベントログを確認するよう案内しています。 (Microsoft Learn)

この段階で初めて、次の設定を確認します。

  • BlockNonAdminUserInstall
  • AllowAllTrustedApps
  • AllowDevelopmentWithoutDevLicense
  • AppLocker
  • Windows Defender Application Control
  • App Readiness Service
  • MSIXのデジタル署名
  • パッケージファミリ名の許可設定

403／404で失敗しやすい対応

VM側の通信だけを確認する

SlimCore MSIXを取得するのはエンドポイント側のプラグインです。VMからoffice.netへ接続できても、原因の切り分けにはなりません。

teams.microsoft.comだけを許可する

SlimCoreの取得には*.office.netが使用されます。Teamsのサインインやチャットが正常でも、SlimCoreだけ取得できない構成は起こり得ます。

404をすべてMicrosoft側の問題と判断する

プロキシのキャッシュ、URL書き換え、フィルタリングによって404が生成される可能性があります。直接経路との比較をせずにエスカレーションすると、切り分け不足として追加調査を求められます。

403／404でAppLockerを変更する

403／404はダウンロード段階のエラーです。AppLockerやAllowAllTrustedAppsは、ダウンロード後の登録・実行エラーで確認します。

非公式サイトからMSIXを入手する

SlimCoreはTeamsと対応するバージョンが使用されます。非公式な配布元から取得したMSIXを手動導入すると、バージョン不整合や署名確認上の問題につながります。

TLSインスペクションを全体で無効化する

原因確認前にMicrosoft関連通信を一括除外すると、セキュリティ範囲を必要以上に広げます。まず対象端末、対象FQDN、対象時間を限定した比較テストで影響を確認します。

Microsoftへ問い合わせる際にそろえる情報

404が複数のネットワーク経路で再現し、プロキシ干渉を除外できた場合は、Microsoft側のパッケージ公開状況を確認するために問い合わせます。

項目記録する内容
発生日時タイムゾーンを含む正確な日時
影響範囲1台、1拠点、全社、特定ユーザーなど
エラーコード404、3235、loadErrc、deployErrc
VDI基盤AVD、Windows 365、Citrix、Omnissaなど
VM側情報Teamsバージョン、OS、イメージ更新日
エンドポイント情報OS、Windows AppやCWAのバージョン
プラグイン情報MsTeamsPluginの種類とバージョン
要求パッケージSlimCoreのパッケージ名とバージョン
通信先FQDN、URLパス、リダイレクト先
HTTP情報ステータス、レスポンスヘッダー、本文
経路比較プロキシ経由と許可された別経路の結果
ネットワーク情報送信元グローバルIP、拠点、プロキシ製品
証跡Teamsログ、プロキシログ、イベントログ

404については、「アクセスできない」という説明だけでなく、どのSlimCoreバージョンを、どのURLから取得しようとして404になったかを提示することが重要です。

修正後の確認項目

ネットワークまたは配布側の問題を修正した後は、次の順番で正常性を確認します。

  1. Teamsを終了し、再起動する
  2. 必要に応じてTeamsの「仮想デスクトップの最適化と再起動」を実行する
  3. 新しいTeamsログに403／404が記録されていないことを確認する
  4. Get-AppxPackage Microsoft.Teams.SlimCore*でHostとFrameworkを確認する
  5. パッケージのStatusがOkであることを確認する
  6. エンドポイント上でMsTeamsVdi.exeが起動していることを確認する
  7. TeamsのVDI状態表示がSlimCoreベースの最適化になっていることを確認する

正常に最適化された環境では、AVD／Windows 365ではリモートデスクトップクライアント、Citrixではwfica32.exeの配下でMsTeamsVdi.exeが動作します。また、TeamsのVDI状態インジケーターからSlimCoreベースの最適化状態を確認できます。 (Microsoft Learn)

Teams VDIのSlimCore MSIXでHTTP 403／404が出た場合は、まずエラー発生時刻とコードをTeamsログで確定し、エンドポイント側の*.office.netへの経路を調べます。403ではプロキシやURLフィルタの拒否を優先し、404ではプロキシ経由と別経路を比較したうえで、CDN上のパッケージ公開問題を判断してください。

Teams
Microsoft Teams MSIX HTTP 404 SlimCore Teams VDI HTTP 403

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次