MENU

Teams VDIエラー15615／1951の直し方｜AllowAllTrustedAppsとMSIX署名を確認

Teams

Teams VDI 2.0でSlimCoreVdiのエラー15615／1951が発生した場合、最初に疑うべきなのは接続先VMではなく、利用者側のWindows端末に適用されたMSIXインストールポリシーです。

対処の要点は、SlimCoreVdiのMSIXに有効なMicrosoft署名があることを確認し、AllowAllTrustedAppsを有効化したうえで、信頼済みのMicrosoft Store以外のソースからアプリをインストールできる状態にすることです。Teamsの再インストールだけでは直らないケースが多いため、物理PCやシンクライアント側の設定を確認してください。Microsoftは、15615／1951をERROR_INSTALL_POLICY_FAILUREとして案内しています。(Microsoft Learn)

目次

Teams VDIエラー15615／1951が示す意味

Teams VDI 2.0のログでは、次の組み合わせで記録されることがあります。

ログ項目エラーコード
loadErrc15615
deployErrc1951
Windowsエラー名ERROR_INSTALL_POLICY_FAILURE

このエラーは、SlimCoreVdiのMSIXパッケージをWindows Package Managerがインストールできなかったことを示します。Windowsの一般的なエラーメッセージでは、開発者ライセンスまたはサイドローディングが許可されたシステムが必要である旨が表示されます。

ただし、Teams VDIで開発作業をするわけではありません。最初からWindowsの開発者モードを全面的に有効化するのではなく、次の3点を優先して確認します。

  • MSIXに有効なMicrosoft署名があるか
  • AllowAllTrustedAppsが明示的に無効化されていないか
  • Microsoft Store以外の信頼済みソースが許可されているか

修正対象はVDIの仮想マシンではなくエンドポイント

Teams VDI 2.0では、仮想マシン上のTeamsアプリとは別に、接続元端末上でSlimCoreメディアエンジンが動作します。

Azure Virtual DesktopやWindows 365ではWindows AppまたはRemote Desktopクライアント、CitrixではCitrix Workspace appに組み込まれたプラグインが、必要なSlimCore MSIXを取得します。その後、接続元端末のApp Readiness Serviceを使ってMSIXをステージングおよび登録します。(Microsoft Learn)

そのため、次のような対応だけでは解決しないことがあります。

  • VDIイメージ上のTeamsを再インストールする
  • Teamsのキャッシュを削除する
  • ユーザープロファイルを作り直す
  • 仮想マシン側だけでグループポリシーを変更する

確認すべきなのは、利用者がVDI接続に使っている次の端末です。

  • Windows PC
  • Windowsシンクライアント
  • Azure Virtual Desktop接続端末
  • Windows 365接続端末
  • Citrix Workspace appを実行している端末

SlimCoreの新しい構成では、HostパッケージとFrameworkパッケージに分かれています。Teamsが更新されると、対応する新しいFrameworkパッケージが必要になる場合があります。

そのため、昨日まで正常だった環境でも、Teams更新後に新しいMSIXの登録だけがポリシーで拒否され、突然15615が発生する可能性があります。(Microsoft Learn)

まずログで15615／1951を確認する

設定を変更する前に、本当にMSIXポリシーが原因なのかをログで確認します。

Teamsログを取得する

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

Ctrl + Alt + Shift + 1

ダウンロードフォルダーにTeamsログのZIPファイルが生成されます。PROD-WebLogs-*.zip内のCoreフォルダーを確認し、vdi_debug.txtから次の文字列を検索してください。

loadErrc
deployErrc

次のような値があれば、この記事の対処対象です。

loadErrc=15615
deployErrc=1951

TeamsログのloadErrcは、MsTeamsVdi.exeの起動やRPC接続時のエラーを示します。deployErrcは、プラグインがSlimCore MSIXを取得し、端末に展開する際のエラーを示します。(Microsoft Learn)

エンドポイントのAppXイベントログを確認する

利用者側のWindows端末でイベントビューアーを開き、次のログを確認します。

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

特にAppXDeployment-ServerのOperationalログを確認してください。

確認する内容は次のとおりです。

確認項目見るべき内容
パッケージ名Microsoft.Teams.SlimCoreVdiを含むか
エラーコード15615、1951、0x80073CF9など
ポリシー関連の記述install policy、sideload、trusted app
署名関連の記述publisher、certificate、signature
実行ユーザー管理者ではないユーザーで失敗していないか

Teamsログは仮想マシンで取得しますが、AppXDeploymentのログは接続元端末で確認する点に注意してください。(Microsoft Learn)

SlimCoreVdiのエラー15615を直す手順

Windowsを最新の累積更新プログラムまで更新する

最初に、接続元端末へ最新のWindows累積更新プログラムを適用します。

Microsoftは、AllowAllTrustedAppsが無効な場合にSlimCore MSIXのインストールが失敗する問題について、Windows 10のKB5031445、Windows 11のKB5031455、Windows 10 1809のKB5055519、またはそれ以降の累積更新プログラムで修正されたと案内しています。(Microsoft Learn)

これらは累積更新プログラムであるため、古いKBを個別に導入するのではなく、対象OSで利用可能な最新の品質更新プログラムを適用するのが基本です。

更新後は端末を再起動してから再テストします。

SlimCore MSIXのMicrosoft署名を確認する

対象のSlimCore MSIXファイルを確認できる場合は、次の手順で署名を確認します。

  1. MSIXファイルを右クリックする
    2.［プロパティ］を開く
    3.［デジタル署名］タブを開く
  2. Microsoftの署名が存在することを確認する
    5.［詳細］を開き、デジタル署名が有効であることを確認する

Microsoftのトラブルシューティング情報では、SlimCoreVdiのMSIXにはMicrosoftの有効なStore対応署名が付与されていると説明されています。組織固有の証明書ポリシーやアプリ制御設定によって、その署名が信頼されない状態になっていないか確認してください。(Microsoft Learn)

署名が無効または存在しない場合は、先に次の問題を調査します。

  • MSIXファイルの破損
  • 非公式な配布元から取得していないか
  • 端末の日時が大きくずれていないか
  • ルート証明書の更新が止められていないか
  • セキュリティ製品によってファイルが変更されていないか
  • 独自の証明書信頼ポリシーでMicrosoft署名が拒否されていないか

署名が確認できないパッケージに対して、信頼済みアプリの許可だけを広げるべきではありません。

グループポリシーでAllowAllTrustedAppsを有効化する

ドメインまたはローカルグループポリシーを使用する場合は、接続元端末に適用されるポリシーを編集します。

コンピューターの構成
└ 管理用テンプレート
  └ Windows コンポーネント
    └ アプリ パッケージの展開
      └ Allow all trusted apps to install

英語名がAllow all trusted apps to installのポリシーを有効に設定します。

このポリシーは、ローカルコンピューターが証明書チェーンを検証できる、信頼済みのLOBアプリや開発者署名済みパッケージアプリのインストールを許可します。対応するレジストリ値は次のとおりです。(Microsoft Learn)

キー:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Appx

値名:
AllowAllTrustedApps

種類:
REG_DWORD

値の意味は次のようになります。

値状態
0明示的に拒否
1明示的に許可
値なし未構成

15615の切り分けでは、未構成のままにするのではなく、一度1として明示的に許可し、症状が変化するか確認するのが分かりやすい方法です。

ポリシーを変更した後は、管理者権限のコマンドプロンプトまたはPowerShellで次を実行します。

gpupdate.exe /force

その後、接続元端末を再起動してください。

PowerShellでAllowAllTrustedAppsを確認する

現在の設定は、管理者権限のPowerShellで確認できます。

$policyPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Appx'

Get-ItemProperty -Path $policyPath -ErrorAction SilentlyContinue |
    Select-Object AllowAllTrustedApps,
                  BlockNonAdminUserInstall,
                  AllowDevelopmentWithoutDevLicense

AllowAllTrustedAppsが0なら、明示的にインストールが拒否されています。

ローカル管理端末で一時的に切り分ける場合は、次のコマンドで1を設定できます。

$policyPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Appx'

New-Item -Path $policyPath -Force | Out-Null

New-ItemProperty `
    -Path $policyPath `
    -Name 'AllowAllTrustedApps' `
    -PropertyType DWord `
    -Value 1 `
    -Force | Out-Null

gpupdate.exe /force

ドメインGPOやIntuneで管理されている端末では、直接変更したレジストリ値が次回同期時に元へ戻る可能性があります。恒久対応では、レジストリを直接編集せず、設定元のGPOまたはMDMプロファイルを修正してください。

どのGPOが値を設定しているか分からない場合は、次のコマンドで適用結果を出力します。

gpresult.exe /h C:\Temp\gpresult.html

生成されたレポートで、アプリパッケージ展開に関するコンピューターポリシーを確認します。

IntuneやMDMでAllowAllTrustedAppsを設定する

MDMでは、ApplicationManagement Policy CSPを使用できます。

OMA-URI:
./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/AllowAllTrustedApps

データ型:
Integer

値:
1

この設定はユーザー単位ではなく、デバイス単位で適用されます。MicrosoftのPolicy CSPでは、0が明示的な拒否、1が明示的な許可、65535が未構成として定義されています。(Microsoft Learn)

Intuneで設定する場合は、対象となるVDI接続端末のデバイスグループへ割り当てます。仮想マシンのグループへ割り当てても、SlimCore MSIXがインストールされる物理端末には反映されません。

Microsoft Store以外の信頼済みソースを許可する

AllowAllTrustedAppsに加え、Windows側でMicrosoft Store以外からのアプリ取得が禁止されていないか確認します。

Windows 11では、次の画面を開きます。

設定
→ アプリ
→ アプリの詳細設定
→ アプリを入手する場所の選択

Microsoft Store以外も許可する選択肢にします。英語UIではAnywhereです。

Windows 10では、次の画面を確認します。

設定
→ 更新とセキュリティ
→ 開発者向け
→ アプリのサイドローディング

Microsoftによると、通常はWindows 10、Windows 11ともに信頼済みの非Storeソースを利用できる状態ですが、組織のGPO、MDM、セキュリティベースラインによって無効化されている場合があります。(Microsoft Learn)

画面上の項目がグレーアウトしている場合は、利用者が変更するのではなく、GPOまたはMDMの管理者が設定を変更します。

BlockNonAdminUserInstallも併せて確認する

AllowAllTrustedAppsを有効にしても直らない場合は、次の値を確認します。

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Appx
BlockNonAdminUserInstall

値が1の場合、管理者ではないユーザーによるWindowsアプリパッケージのインストールが禁止されています。Teams VDIのプラグインはユーザーセッション中にSlimCore MSIXを登録するため、このポリシーが障害になることがあります。(Microsoft Learn)

単純な切り分けでは、BlockNonAdminUserInstallを無効または未構成にして再テストします。

ただし、セキュリティ上の理由で非管理者によるMSIXインストールを禁止している環境では、ポリシー全体を解除せず、許可するパッケージファミリ名を限定する方法があります。

新しいSplit MSIX構成では、Microsoftが例示している主なパッケージ名は次のとおりです。

Microsoft.Teams.SlimCoreVdiHost.win-x64_8wekyb3d8bbwe
Microsoft.Teams.SlimCoreVdiFwk.*_8wekyb3d8bbwe

まとめて指定する正規表現の例は次のとおりです。

Microsoft.Teams.SlimCoreVdi*.*_8wekyb3d8bbwe

対応するグループポリシーは、次の場所にあります。

コンピューターの構成
→ 管理用テンプレート
→ Windows コンポーネント
→ アプリ パッケージの展開
→ Allowed package family names for non-admin user install

この設定を利用するには、Microsoftが指定するWindows更新プログラムまたはそれ以降の累積更新プログラムが必要です。(Microsoft Learn)

AppLockerやWDACでMSIXが拒否されていないか確認する

端末でAppLockerまたはWindows Defender Application Controlを使用している場合、AllowAllTrustedAppsとは別の層でSlimCoreVdiが拒否されることがあります。

確認対象は次のとおりです。

  • AppLockerの「パッケージ アプリの規則」
  • WDACの署名者ルール
  • Microsoft署名アプリに対する例外設定
  • SlimCoreVdiのパッケージファミリ名
  • AppXDeploymentイベント内のポリシー拒否記録

AppLockerやWDACを全面的に無効化して解決する方法は推奨できません。Microsoft署名、発行元、パッケージファミリ名などを使い、SlimCoreVdiだけを許可するルールを作成します。Microsoftも、これらのアプリ制御機能がMSIXインストールを阻止する可能性を案内しています。(Microsoft Learn)

App Readiness Serviceが無効化されていないか確認する

SlimCore MSIXのステージングと登録には、接続元端末のApp Readiness Serviceが使用されます。

サービスの状態はPowerShellで確認できます。

Get-CimInstance Win32_Service `
    -Filter "Name='AppReadiness'" |
    Select-Object Name, State, StartMode

サービスがセキュリティチューニングやシンクライアント用の最適化スクリプトによってDisabledにされている場合は、MSIX登録が失敗する可能性があります。

常時実行させる必要はありませんが、必要時に起動できる設定にします。組織のハードニングテンプレートで無効化されている場合は、テンプレート側を修正してください。SlimCoreのステージングと登録がApp Readiness Serviceに依存することは、MicrosoftのTeams VDI構成情報でも明記されています。(Microsoft Learn)

修正後にSlimCoreVdiが登録されたか確認する

ポリシー変更と端末再起動後、接続元端末で次のコマンドを実行します。

Get-AppxPackage Microsoft.Teams.SlimCore* |
    Select-Object Name,
                  Version,
                  Architecture,
                  PackageFamilyName

新しいSplit MSIX構成では、HostとFrameworkに該当するパッケージが表示されます。

Microsoft.Teams.SlimCoreVdiHost...
Microsoft.Teams.SlimCoreVdiFwk...

古い構成では、単一のMicrosoft.Teams.SlimCoreVdi...パッケージとして表示される場合があります。Microsoftも、SlimCoreパッケージの確認方法としてGet-AppxPackage Microsoft.Teams.SlimCore*を案内しています。(Microsoft Learn)

続いて、次の順番で再接続します。

  1. Teamsを完全に終了する
  2. VDIセッションからサインアウトまたは切断する
  3. Windows App、Remote Desktop、Citrix Workspace appを再起動する
  4. VDIへ再接続する
  5. Teamsを起動する
  6. 通話またはテスト通話を実行する

Teamsがプラグインを初めて検出した場合、新しいSlimCoreスタックへ切り替わるためにTeamsの再起動が必要になることがあります。(Microsoft Learn)

復旧したかを判断するポイント

次のすべてを確認してください。

確認項目正常時の目安
SlimCoreパッケージGet-AppxPackageで表示される
Teams VDI状態SlimCore接続または最適化済みと表示される
connectedStackremote
loadErrc0
deployErrc0
通話音声、カメラ、画面共有が動作する
AppXイベント新しい展開エラーが記録されない

connectedStack: remoteだけでは、メディアスタックの初期化まで成功したことを保証できません。Microsoftの説明でも、仮想チャネルへ接続できていても通話開始に失敗する可能性があるとされています。

そのため、connectedStackだけで判断せず、loadErrc=0、deployErrc=0、SlimCoreパッケージの登録、実際の通話動作を組み合わせて確認します。(Microsoft Learn)

15615と間違えやすい関連エラー

SlimCoreが接続されない場合でも、原因がポリシーとは限りません。

loadErrcdeployErrc主な原因
156151951MSIXインストールポリシー違反
543アクセス拒否、非管理者インストール制限、AppX登録処理中
126010083AppLockerなどのポリシーで無効化
4033227プロキシやネットワークがMicrosoft CDNを拒否
4043235CDN上のパッケージ取得失敗、プロキシ干渉
300524043MSIXダウンロードのタイムアウト
300724058SlimCoreの取得またはインストールのタイムアウト
300024002展開不要を示す正常系コード

特に3000／24002はエラーではありません。コードだけを見て障害と判断せず、Microsoftの対応表で意味を確認してください。(Microsoft Learn)

セキュリティを下げずに運用するための注意点

AllowAllTrustedApps=1は、Teams SlimCoreVdiだけを許可する設定ではありません。ローカル端末で証明書チェーンを検証できる、信頼済みのLOBアプリや開発者署名済みパッケージアプリにも影響します。(Microsoft Learn)

そのため、本番環境では次の方針が適切です。

  • 先にWindowsを最新の累積更新プログラムへ更新する
  • Microsoft署名が有効なことを確認する
  • GPOとMDMの競合を解消する
  • 非管理者インストールを制限する場合はパッケージファミリ名で許可する
  • AppLockerやWDACを全面解除せず、Teams用の許可ルールを作る
  • 直接レジストリ変更は原因切り分けに限定する
  • 検証端末で通話、カメラ、画面共有まで確認してから全体展開する

最短の復旧手順は、接続元端末で15615／1951を確認し、Microsoft署名、AllowAllTrustedApps、非Storeソースの許可を順番に見直すことです。それでも直らない場合は、BlockNonAdminUserInstall、AppLocker、WDAC、App Readiness Serviceを確認してください。

最終的には、Get-AppxPackage Microsoft.Teams.SlimCore*でパッケージが表示され、TeamsログがloadErrc=0、deployErrc=0になり、実際の通話が正常に動作するところまで確認して対応完了とします。

Teams
MSIX Teams VDI SlimCoreVdi AllowAllTrustedApps

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次