Teams VDIエラー5／16389の解決方法｜非管理者のSlimCore起動を許可するポリシー設定

Teams VDI 2.0で、管理者アカウントではSlimCoreが起動するのに、非管理者ユーザーではエラー5または16389が発生する場合は、ユーザー側エンドポイントのBlockNonAdminUserInstallを最初に確認します。

このポリシーが有効だと、非管理者によるMSIXパッケージのインストール開始が制限され、SlimCoreVdiの自動登録やMsTeamsVdi.exeの起動に失敗することがあります。修正対象はTeamsを実行するVDI仮想マシンではなく、Windows AppやCitrix Workspace appが動作しているエンドポイントです。

推奨される対応は、非管理者インストール制限を全面的に解除することではありません。対応するWindows更新プログラムを適用したうえで、「管理者以外のユーザーインストールで許可されるパッケージファミリ名」ポリシーにSlimCore関連パッケージだけを登録します。Microsoftも、エラー16389は通常エラー5と同じ状態であり、非管理者ユーザーの場合はBlockNonAdminUserInstallが有力な原因になると説明しています。(Microsoft Learn)

Teams VDIエラー5／16389が示している状態

Teams VDI 2.0のログには、主にloadErrcとdeployErrcの2種類のコードが記録されます。

deployErrcは、SlimCore MSIXのダウンロード、ステージング、登録で発生したエラーです。一方、loadErrcは、プラグインがエンドポイント上でMsTeamsVdi.exeを起動し、RPC接続を確立しようとした段階のエラーです。(Microsoft Learn)

エラーコード	意味	主な確認対象
`loadErrc=5`	`ERROR_ACCESS_DENIED`。`MsTeamsVdi.exe`の起動に失敗	`BlockNonAdminUserInstall`、AppX登録処理の混雑
`16389`	Windows Package Managerが返す`E_FAIL`	多くの場合はエラー5と同じ。非管理者インストール制限
`loadErrc=0`、`deployErrc=0`	SlimCoreの接続成功	対応不要
`3000`、`3001`	配置不要、またはSlimCore読み込み済み	実際にはエラーではない

エラー5は、必ずしもポリシーだけが原因とは限りません。ユーザーのログオン直後に多数のMSIXパッケージを登録しており、App Readiness ServiceがSlimCoreVdiの登録を完了できなかった場合にも発生します。

そのため、エラーが一時的に出ただけなのか、標準ユーザーで毎回再現するのかを確認してからポリシーを変更することが重要です。(Microsoft Learn)

なぜ管理者では動き、非管理者では失敗するのか

Teams VDI 2.0では、VDI仮想マシン内のTeamsが仮想チャネルを通じて、ユーザー端末側のVDIプラグインに接続します。

その後、プラグインがMicrosoftの配信元から適切なSlimCore MSIXを取得し、エンドポイントのApp Readiness Serviceを使用してパッケージをステージング、登録します。実際に音声、映像、画面共有などのメディア処理を行うMsTeamsVdi.exeも、VDI仮想マシンではなくエンドポイント上で動作します。(Microsoft Learn)

したがって、次のような構成では、管理者と非管理者で結果が変わります。

管理者ユーザーはMSIXパッケージを登録できる
非管理者ユーザーはBlockNonAdminUserInstallによって登録を拒否される
SlimCoreを起動できず、サーバー側レンダリングまたは従来の最適化へフォールバックする
Teamsには「SlimCore Media Not Connected」やエラー5、16389が表示される

この問題に対して、VDIマスターイメージだけのグループポリシーを変更しても解決しません。Windows App、リモートデスクトップクライアント、Citrix Workspace appなどを実行している物理端末またはシンクライアント側を確認します。

ポリシー変更前に原因を切り分ける

同じエンドポイントで管理者と標準ユーザーを比較する

可能であれば、同じエンドポイント、同じVDI接続先、同じTeamsバージョンで、次の比較を行います。

結果	判断
管理者では成功し、標準ユーザーだけ失敗	`BlockNonAdminUserInstall`などのユーザー権限制限が有力
管理者と標準ユーザーの両方で失敗	プラグイン、仮想チャネル、ネットワーク、AppLockerなども調査
ログオン直後だけ失敗し、数分後は成功	AppX登録処理またはApp Readiness Serviceの混雑を疑う
端末によって結果が異なる	エンドポイントごとのOS更新、GPO、MDM適用状態を比較

管理者として常用することは解決策ではありません。管理者アカウントでの確認は、原因を絞り込むための一時的な比較テストとして使用します。

TeamsのVDIログからエラーコードを確認する

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

Ctrl + Alt + Shift + 1

ダウンロードフォルダーにTeamsのログZIPが作成されます。展開後、vdi_debug.txtやDiagnostics-logs.txtを対象に、次の文字列を検索します。

loadErrc
deployErrc
vdiBridgeEventsHandler
SlimCore

エラー5の場合は、次のような値が確認対象です。

loadErrc=5

エラー16389は、Windows Package Manager側のイベントやTeamsの診断情報に記録されることがあります。Microsoftは、16389を通常のloadErrc=5と同じアクセス拒否の状態として扱っています。(Microsoft Learn)

エンドポイントのレジストリ値を確認する

エンドポイントで管理者権限のPowerShellを開き、次のスクリプトを実行します。

$paths = @(
    'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Appx',
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock'
)

foreach ($path in $paths) {
    if (Test-Path $path) {
        Write-Host "`n[$path]"
        Get-ItemProperty -Path $path |
            Select-Object `
                BlockNonAdminUserInstall,
                AllowAllTrustedApps,
                AllowDevelopmentWithoutDevLicense
    }
}

確認の目安は次のとおりです。

レジストリ値	状態	判断
`BlockNonAdminUserInstall`	`1`	非管理者によるWindowsアプリパッケージのインストール開始を禁止
`BlockNonAdminUserInstall`	`0`または値なし	無効または未構成
`AllowAllTrustedApps`	`0`	SlimCore MSIXの登録に別の制限がかかる可能性
`AllowDevelopmentWithoutDevLicense`	`0`	サイドローディング関連エラーでは追加確認が必要

BlockNonAdminUserInstall=1であっても、それだけで原因確定とは限りません。後述するSlimCoreの許可リストが構成済みであれば、非管理者インストール制限を維持したままSlimCoreだけを許可できます。(Microsoft Learn)

適用されたコンピューターポリシーを確認する

ドメインGPOを使用している場合は、エンドポイント上で結果セットを取得します。

gpresult.exe /scope computer /h "$env:TEMP\gpresult-computer.html" /f

生成されたHTMLで、次のポリシーを検索します。

Prevent non-admin users from installing packaged Windows apps
Allowed package family names for non-admin user install
Allow all trusted apps to install

レジストリを手動変更して一時的に直っても、GPOやMDMの再同期によって元に戻ることがあります。恒久対応では、値の設定元となっているGPO、MDM、シンクライアント管理製品を修正します。

SlimCoreVdiを許可する推奨ポリシー修正

対応するWindows更新プログラムを適用する

BlockNonAdminUserInstallを維持したまま特定のパッケージを許可するには、「Allowed package family names for non-admin user install」ポリシーを利用できる状態にします。

MicrosoftのTeams VDI資料では、次の更新プログラムまたは後続の累積更新プログラムが案内されています。通常は、該当OSで利用可能な最新の品質更新プログラムを適用します。(Microsoft Learn)

エンドポイントOS	必要な更新プログラム
Windows 11 22H2／23H2	KB5052094または後続の更新
Windows 11 24H2	KB5052093または後続の更新
Windows 10 22H2	KB5055612または後続の更新

更新後、次の場所に新しいポリシーが表示されることを確認します。

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

非管理者インストール制限を維持したままSlimCoreを許可する

セキュリティ要件から非管理者のMSIXインストールを制限している場合は、次の方針で設定します。

Prevent non-admin users from installing packaged Windows appsは有効のままにする
Allowed package family names for non-admin user installを有効にする
SlimCore関連のパッケージファミリ名を許可リストへ登録する

現在の分割MSIXアーキテクチャでは、HostとFrameworkの両方を許可する必要があります。

対象	許可する値
旧SlimCore単一パッケージ	`Microsoft.Teams.SlimCoreVdi.*_8wekyb3d8bbwe`
分割MSIXのHost	`Microsoft.Teams.SlimCoreVdiHost.win-x64_8wekyb3d8bbwe`
分割MSIXのFramework	`Microsoft.Teams.SlimCoreVdiFwk.*_8wekyb3d8bbwe`

Microsoftの資料では、旧パッケージと新しい分割パッケージをまとめて対象にする正規表現として、次の例も示されています。

Microsoft.Teams.SlimCoreVdi*.*_8wekyb3d8bbwe

ただし、運用時の監査性を重視するなら、HostとFrameworkを分けて登録した方が、何を許可しているのか確認しやすくなります。

このポリシーに入力する値はECMAScript形式の正規表現として処理されます。パッケージファミリ名がルールに一致すれば、BlockNonAdminUserInstallによる拒否を回避できますが、AppLocker、WDAC、信頼済みアプリ関連ポリシーなど、別の制御によって拒否される可能性は残ります。(Microsoft Learn)

Hostだけを許可しない

分割MSIXでは、役割が異なる2種類のパッケージが使用されます。

Hostは、Windowsへのアプリ登録とMsTeamsVdi.exeの起動を担当する
Frameworkは、Teamsのバージョンに対応したリアルタイムメディアライブラリを提供する

Hostだけを許可すると、「Microsoft Teams VDI Optimizer」は表示されても、必要なFrameworkを登録できず、最適化が完成しない可能性があります。Frameworkのパッケージファミリ名にはバージョン部分が含まれるため、完全一致ではなく、Microsoftが案内する正規表現を使用します。(Microsoft Learn)

ドメインGPOで新しいポリシーが表示されない場合

エンドポイントを更新しても、グループポリシー管理エディターに「Allowed package family names for non-admin user install」が表示されないことがあります。

ドメイン環境でCentral Storeを使用している場合、GPO管理ツールは管理端末のローカルADMXではなく、SYSVOL内のCentral Storeを優先します。そのため、Central Storeに古いAppxPackageManager.admxが残っていると、新しいポリシーを編集できません。

Microsoftによると、AllowedNonAdminPackageFamilyNameRulesは、Windows 11 23H2および24H2向けの2025年1月のサービス更新でAppxPackageManager.admxに追加されました。Central Storeを使用している組織では、更新済みのADMXと対応言語のADMLをテスト環境で確認してからCentral Storeへ反映します。(Microsoft Learn)

確認対象は主に次のファイルです。

AppxPackageManager.admx
ja-JP\AppxPackageManager.adml

Central Store全体を未検証のファイルで上書きすると、既存ポリシーとの不整合が起きる可能性があります。現在のPolicyDefinitionsを退避し、バージョン別のフォルダーで検証してから切り替える方法が安全です。

ポリシー適用後にSlimCoreを再登録させる

ポリシーを変更したら、エンドポイントで次を実行します。

gpupdate.exe /force

その後、次の順序で再試行します。

VDI仮想マシン内のTeamsを完全終了する
Windows App、リモートデスクトップクライアント、Citrix Workspace appを終了する
VDIセッションへ再接続する
Teamsを起動する
必要に応じてTeamsをもう一度再起動する

プラグインが初めて検出された場合、従来のWebRTC最適化からSlimCoreへ切り替えるために、Teamsの再起動が1回必要になることがあります。(Microsoft Learn)

ポリシーを正しく変更しても登録状態が残っている場合は、エンドポイントを再起動してから、影響を受けていた標準ユーザーで再検証します。

修正後にSlimCoreの登録と起動を確認する

影響を受けていたユーザーでMSIX登録を確認する

エンドポイントへ対象の非管理者ユーザーでサインインし、そのユーザーのPowerShellで次を実行します。

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

分割MSIXを使用している場合は、概ね次の2種類が表示されます。

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

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

StatusがOkになっている
HostとFrameworkの両方が表示される
FrameworkのバージョンがTeams側の要求に対応している
管理者アカウントではなく、実際に利用する標準ユーザーで登録されている

Get-AppxPackageを管理者アカウントで実行すると、その管理者に登録されたパッケージだけを確認してしまうことがあります。非管理者ユーザー固有の問題を調査するときは、対象ユーザーのコンテキストで確認してください。

また、複数のFrameworkが表示されても、直ちに異常とは限りません。Microsoftは、異なるVDI環境やTeamsバージョンとの互換性を保つため、複数のSlimCore Frameworkを共存させる設計を採用しています。不要と判断して一括削除すると、別のVDI環境で最適化できなくなる可能性があります。(Microsoft Learn)

MsTeamsVdi.exeの起動を確認する

SlimCoreが正常に動作している場合、エンドポイントのタスクマネージャーまたはProcess ExplorerでMsTeamsVdi.exeを確認できます。

VDI製品	主な親プロセス
Azure Virtual Desktop／Windows 365	`msrdc.exe`またはWindows App関連プロセス
Citrix	`wfica32.exe`

Process Explorerを使用する場合は、親プロセスの下部ペインをDLL表示に切り替え、次のプラグインが読み込まれているか確認します。

MsTeamsPluginAvd.dll
MsTeamsPluginCitrix.dll

パッケージは登録されているのにMsTeamsVdi.exeが起動しない場合は、AppX登録、アプリ実行エイリアス、RPC、プラグイン読み込みの問題へ調査範囲を広げます。(Microsoft Learn)

Teamsの最適化状態を確認する

Teamsの左上にあるVDI状態インジケーター、または「設定」からバージョンと最適化状態を確認します。

SlimCoreベースの最適化が成功していれば、環境に応じてSlimCore Media Optimizedであることが表示されます。AVDでは、Microsoft公式資料上の表示は次のように区別されています。

AVD SlimCore Media Optimized
AVD Media Optimized

前者がSlimCoreベースの新しい最適化、後者が従来のWebRTCベースの最適化です。(Microsoft Learn)

ポリシー修正後も起動しない場合の確認表

症状・コード	次に確認する項目
標準ユーザーだけエラー5／16389	許可リストの適用結果、PFNの入力ミス、HostとFrameworkの両方
ログオン直後だけエラー5	App Readiness Serviceや他のMSIX登録処理が完了するまで待って再試行
エラー15615	`AllowAllTrustedApps`、サイドローディング、署名の信頼、Windows更新
エラー1260／10083	AppLockerまたはWDACのブロック
エラー2000／16002	エンドポイントのVDIプラグイン未導入、または未読み込み
エラー2003／16026	Citrixの仮想チャネル許可リスト
エラー403／3227	プロキシ、SSL検査、Microsoft CDNへの通信
パッケージはあるがエラー15700	`MsTeamsVdi`のアプリ実行エイリアスやパッケージID
エラー1722	`MsTeamsVdi.exe`とのRPC接続
管理者でも標準ユーザーでも失敗	`BlockNonAdminUserInstall`以外の原因を優先

AppLockerを使用している場合、非管理者パッケージ許可ポリシーで使用した正規表現を、そのままAppLockerへ貼り付けないでください。Microsoftは、AppLockerでは末尾のワイルドカードを処理できないと説明しています。AppLockerまたはWDAC側で、SlimCore Hostとバージョン付きFrameworkに対応できる発行元ルールや例外ルールを別途設計します。(Microsoft Learn)

避けるべき対処方法

非管理者ユーザーへローカル管理者権限を付与する

管理者にすれば動く場合でも、原因となるポリシー設計は残ったままです。Teams VDI最適化のためだけに管理者権限を付与するのではなく、SlimCoreパッケージを限定的に許可します。

BlockNonAdminUserInstallを無条件で無効にする

BlockNonAdminUserInstallを無効または未構成にすれば、すべてのユーザーがWindowsアプリパッケージのインストールを開始できる状態になります。原因確認の一時テストには使えますが、組織のセキュリティ要件がある場合は恒久対応に適しません。(Microsoft Learn)

SlimCore MSIXを一度だけ管理者で手動導入する

SlimCoreは、VDI仮想マシン上のTeamsバージョンと対応するバージョンを使用します。Teamsが更新されると、新しいFrameworkが必要になる可能性があります。

ロックダウン環境でSlimCoreを手動配布する方式もありますが、Microsoftは、Teamsの自動更新を無効にし、Teamsを更新する前に対応するSlimCoreパッケージをエンドポイントへ事前配置することを条件としています。一度だけ手動インストールする方法では、次回更新時に再発する可能性があります。(Microsoft Learn)

WindowsAppsフォルダーの所有権を変更する

C:\Program Files\WindowsAppsは保護されたフォルダーです。登録状態を確認するためにACLや所有権を変更する必要はありません。

Microsoftも、WindowsAppsの所有権を取得するのではなく、Get-AppxPackage Microsoft.Teams.SlimCore*で確認する方法を案内しています。(Microsoft Learn)

エラー5／16389を解決する実務上の進め方

Teams VDI 2.0で非管理者ユーザーだけSlimCoreが起動しない場合は、次の順序で対応すると原因を見失いにくくなります。

TeamsログでloadErrc=5または16389を確認する
修正対象がVDI仮想マシンではなくエンドポイントであることを確認する
BlockNonAdminUserInstallの値と適用元GPOを調べる
エンドポイントへ必要なWindows更新プログラムを適用する
SlimCoreのHostとFrameworkを非管理者インストール許可リストへ追加する
GPOを更新し、VDIクライアントとTeamsを再起動する
対象の標準ユーザーでGet-AppxPackageを実行する
MsTeamsVdi.exeとTeamsのSlimCore最適化表示を確認する

最も重要なのは、非管理者インストール制限を単純に解除するのではなく、SlimCoreのパッケージファミリ名だけを例外として許可することです。

Hostだけを許可してFrameworkを漏らす、ドメインのCentral Storeが古いためポリシーが表示されない、VDI仮想マシン側だけを変更するといった失敗が多いため、エンドポイントの実効ポリシーとパッケージ登録結果まで確認して完了と判断してください。

この記事を書いた人

佐藤健司

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

Teams VDIエラー5／16389の解決方法｜非管理者のSlimCore起動を許可するポリシー設定

Teams VDIエラー5／16389が示している状態

なぜ管理者では動き、非管理者では失敗するのか

ポリシー変更前に原因を切り分ける

同じエンドポイントで管理者と標準ユーザーを比較する

TeamsのVDIログからエラーコードを確認する

エンドポイントのレジストリ値を確認する

適用されたコンピューターポリシーを確認する

SlimCoreVdiを許可する推奨ポリシー修正

対応するWindows更新プログラムを適用する

非管理者インストール制限を維持したままSlimCoreを許可する

Hostだけを許可しない

ドメインGPOで新しいポリシーが表示されない場合

ポリシー適用後にSlimCoreを再登録させる

修正後にSlimCoreの登録と起動を確認する

影響を受けていたユーザーでMSIX登録を確認する

MsTeamsVdi.exeの起動を確認する

Teamsの最適化状態を確認する

ポリシー修正後も起動しない場合の確認表

避けるべき対処方法

非管理者ユーザーへローカル管理者権限を付与する

BlockNonAdminUserInstallを無条件で無効にする

SlimCore MSIXを一度だけ管理者で手動導入する

WindowsAppsフォルダーの所有権を変更する

エラー5／16389を解決する実務上の進め方

この記事を書いた人

コメント

コメントするコメントをキャンセル

Teams VDIエラー5／16389の解決方法｜非管理者のSlimCore起動を許可するポリシー設定

Teams VDIエラー5／16389が示している状態

なぜ管理者では動き、非管理者では失敗するのか

ポリシー変更前に原因を切り分ける

同じエンドポイントで管理者と標準ユーザーを比較する

TeamsのVDIログからエラーコードを確認する

エンドポイントのレジストリ値を確認する

適用されたコンピューターポリシーを確認する

SlimCoreVdiを許可する推奨ポリシー修正

対応するWindows更新プログラムを適用する

非管理者インストール制限を維持したままSlimCoreを許可する

Hostだけを許可しない

ドメインGPOで新しいポリシーが表示されない場合

ポリシー適用後にSlimCoreを再登録させる

修正後にSlimCoreの登録と起動を確認する

影響を受けていたユーザーでMSIX登録を確認する

MsTeamsVdi.exeの起動を確認する

Teamsの最適化状態を確認する

ポリシー修正後も起動しない場合の確認表

避けるべき対処方法

非管理者ユーザーへローカル管理者権限を付与する

BlockNonAdminUserInstallを無条件で無効にする

SlimCore MSIXを一度だけ管理者で手動導入する

WindowsAppsフォルダーの所有権を変更する

エラー5／16389を解決する実務上の進め方

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル