MENU

Teams VDIエラー1260／10083（0x800704EC）の直し方｜AppLockerでSlimCoreを許可

Teams

Microsoft Teams VDI 2.0で「1260／10083」や「0x800704EC」が記録され、SlimCoreによるメディア最適化に失敗する場合、VDIエンドポイント側のAppLockerがSlimCore MSIXパッケージをブロックしている可能性があります。

対処の要点は、問題が起きている物理PCやシンクライアントでAppLockerログを確認し、検証用端末では一時的に監査モードへ変更して原因を切り分けることです。AppLockerが原因と確認できたら、無効化したままにするのではなく、SlimCoreVdiパッケージを許可するルールを追加します。特に重要なのは、VDIセッションホストだけでなく、Windows AppやCitrix Workspaceアプリが動作している接続元エンドポイントを調査することです。(Microsoft Learn)

目次

Teams VDIエラー1260／10083の意味

Microsoftのトラブルシューティング情報では、エラー1260／10083は次のように整理されています。

項目内容
Windowsエラー1260
Teams VDI側の関連コード10083
16進エラーコード0x800704EC
エラー名ERROR_ACCESS_DISABLED_BY_POLICY
主な意味WindowsのポリシーによりSlimCore MSIXをインストールできない
主な原因候補AppLocker、WDAC、MSIX関連GPO、MDMポリシー
基本的な対処AppLockerの無効化による切り分け、またはSlimCoreの許可ルール追加

このエラーは、WindowsパッケージマネージャーがSlimCore MSIXパッケージをステージングまたは登録できないときに発生します。AppLockerが原因になることがありますが、0x800704ECが出たというだけでAppLockerと断定してはいけません。AppLockerイベントとAppX展開ログを照合し、実際に何のポリシーがブロックしたのかを確認する必要があります。(Microsoft Learn)

AppLockerがSlimCoreを止める仕組み

Teams VDI 2.0では、VDIセッション内のTeamsだけで音声や映像を処理するのではなく、接続元エンドポイントにSlimCoreメディアエンジンを配置して処理をオフロードします。

処理の流れは次のとおりです。

VDIセッションホスト上のTeams
        ↓ 仮想チャネル
Windows App／Citrix Workspaceアプリ
        ↓ VDIプラグイン
接続元エンドポイントへSlimCore MSIXをインストール
        ↓
音声・映像・画面共有をエンドポイントで処理

VDIプラグインは、必要なSlimCore MSIXをエンドポイントへダウンロードし、通常は管理者操作なしでサイレントインストールします。しかし、エンドポイントのAppLockerでパッケージアプリのインストールが許可されていなければ、この処理が失敗します。AppLockerのパッケージアプリ規則は、パッケージのインストールと実行の両方を制御します。(Microsoft Learn)

調査する端末を間違えない

エラーはVDIセッション内のTeamsに表示されますが、実際にSlimCore MSIXがインストールされる場所は接続元エンドポイントです。

調査対象主に確認する内容
VDIセッションホスト、VDA、Cloud PCTeams VDIの接続状態、1260／10083、プラグイン関連エラー
物理PC、シンクライアントSlimCore MSIX、AppLocker、AppXDeployment、WDAC、MSIX関連GPO
Citrix管理環境VDIプラグイン、仮想チャネル許可リスト
AVD／Windows 365クライアントWindows App、VDIプラグイン、接続元OSのポリシー

VDIセッションホストにSlimCoreのAppLocker許可ルールを追加しても、接続元エンドポイントでブロックされていれば解決しません。GPOのリンク先やIntuneの割り当て先も、セッションホストではなくエンドポイントを基準に確認してください。(Microsoft Learn)

AppLockerが原因か切り分ける手順

TeamsのVDI状態を確認する

Teamsの左上に表示されるVDI状態インジケーター、またはTeamsのメニューからバージョン情報を確認します。

正常なSlimCore最適化では、AVD環境の場合、次のような表示になります。

AVD SlimCore Media Optimized

問題がある場合は、次のような表示になることがあります。

Azure Virtual Desktop SlimCore Media Not Connected
Citrix SlimCore Media Not Connected

「Media Optimized」とだけ表示される場合は、従来のWebRTC最適化で動作している可能性があります。SlimCoreのMSIXが使われているとは限りません。(Microsoft Learn)

VDIセッション内で1260／10083を確認する

VDIセッションホスト側では、イベントビューアーの次の場所を確認します。

Windowsログ
  └ アプリケーション

次の条件でフィルターします。

項目値
ソースMicrosoft Teams VDI
イベントID0

ソースが選択肢に表示されない場合、Microsoftの案内では管理者権限のPowerShellで次のコマンドを実行する方法が示されています。

New-EventLog -LogName Application -Source "Microsoft Teams VDI"

イベント内に次の組み合わせが記録されていれば、SlimCore MSIXのインストールポリシーを重点的に調査します。

1260
10083
0x800704EC
ERROR_ACCESS_DISABLED_BY_POLICY

Teamsのログは、VDIセッション内で次のキーを押して収集できます。

Ctrl + Alt + Shift + 1

ダウンロードフォルダーに作成されたZIPファイル内のVdi_debug.txtやDiagnostics-logs.txtも確認します。(Microsoft Learn)

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

接続元の物理PCまたはシンクライアントで、イベントビューアーを開きます。

主に確認するログは次の2つです。

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

ログ内で次の文字列を検索します。

0x800704EC
SlimCore
Microsoft.Teams.SlimCoreVdi
Microsoft.Teams.SlimCoreVdiHost
Microsoft.Teams.SlimCoreVdiFwk
blocked by AppLocker

AppXDeployment-Serverに、対象パッケージの展開がAppLockerによってブロックされたことが記録されていれば、AppLockerが原因と判断できます。(Microsoft Learn)

AppLockerのパッケージアプリログを確認する

次に、エンドポイントでAppLockerログを確認します。

アプリケーションとサービス ログ
  └ Microsoft
     └ Windows
        └ AppLocker
           ├ Packaged app-Deployment
           └ Packaged app-Execution

注目するイベントIDは次のとおりです。

イベントID意味
8021監査モードでは実行できたが、適用モードならブロックされる
8022パッケージアプリの実行がブロックされた
8023パッケージアプリのインストールが許可された
8024監査モードではインストールできたが、適用モードならブロックされる
8025パッケージアプリのインストールがブロックされた
8027EXE規則が適用されている一方、パッケージアプリ規則が適切に構成されていない

イベント8022または8025にSlimCoreのパッケージ名が含まれていれば、AppLockerによるブロックがほぼ確定します。監査モードでは、8021または8024が判断材料になります。(Microsoft Learn)

PowerShellでSlimCoreパッケージを確認する

Microsoftは、WindowsAppsフォルダーの所有権を変更して直接確認するのではなく、PowerShellでパッケージを列挙する方法を案内しています。

接続元エンドポイントで次のコマンドを実行します。

Get-AppxPackage Microsoft.Teams.SlimCore*

管理者として、全ユーザーの状態を確認する場合は次のように実行します。

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

正常にインストールされている場合は、たとえば次のようなパッケージが返ります。

Microsoft.Teams.SlimCoreVdiHost.win-x64
Microsoft.Teams.SlimCoreVdiFwk.win-x64.<リリース>

StatusがOkで、HostとFrameworkの両方が確認できるかを調べます。ただし、AppLockerによってインストール前にブロックされている場合、対象パッケージは一覧に表示されません。パッケージが見つからない場合は、イベントログと併せて判断してください。(Microsoft Learn)

有効なAppLockerポリシーを出力する

ローカルポリシーだけでなく、ドメインGPOを含めた有効なAppLockerポリシーを確認します。

New-Item -ItemType Directory -Path C:\Temp -Force

Get-AppLockerPolicy -Effective -Xml |
    Set-Content C:\Temp\AppLocker-Effective.xml

出力したXMLで、Appxまたはパッケージアプリ規則を確認します。

インストール済みのSlimCoreパッケージを、出力したポリシーに対してテストすることもできます。

Get-AppxPackage Microsoft.Teams.SlimCore* |
    Test-AppLockerPolicy `
        -XmlPolicy C:\Temp\AppLocker-Effective.xml `
        -User "DOMAIN\UserName"

Get-AppLockerPolicyは、GPO経由で展開されたAppLockerポリシーを取得するコマンドです。AppLocker CSPや一部のMDM構成は正しく反映されないため、Intuneなどを利用している場合は管理画面側の割り当ても確認してください。(Microsoft Learn)

修正方法：AppLockerを監査モードにして原因を確定する

本番環境でいきなりAppLockerを全面的に無効化するのではなく、まず検証用エンドポイントまたは限定グループで、パッケージアプリ規則を「監査のみ」に変更します。

ドメインGPOの場合は、次の場所を開きます。

コンピューターの構成
  └ ポリシー
     └ Windowsの設定
        └ セキュリティの設定
           └ アプリケーション制御ポリシー
              └ AppLocker

AppLockerを右クリックしてプロパティを開き、「パッケージアプリの規則」を「監査のみ」に変更します。

ポリシーを反映します。

gpupdate /force

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

  1. Teamsを完全終了する
  2. VDIセッションを切断する
  3. Windows AppまたはCitrix Workspaceアプリを終了する
  4. VDIクライアントを再起動する
  5. VDIへ再接続する
  6. Teamsを起動する
  7. VDI状態インジケーターを確認する

監査モードにするとエラーが解消し、イベント8024が記録される場合、AppLocker規則が原因です。監査モードは原因確認には有効ですが、そのまま恒久運用するのではなく、必要な許可ルールを追加してから適用モードへ戻します。(Microsoft Learn)

SlimCore MSIXの許可ルールを追加する

許可対象のパッケージを確認する

SlimCoreには、旧一体型パッケージと新しい分割パッケージがあります。環境のTeams、VDIクライアント、プラグインのバージョンによって使用されるパッケージが異なります。

種類パッケージ名の例・パターン特徴
旧一体型Microsoft.Teams.SlimCoreVdi.win-x64.<release>リリースごとに名前が変わる
HostMicrosoft.Teams.SlimCoreVdiHost.win-x64パッケージファミリ名が固定
FrameworkMicrosoft.Teams.SlimCoreVdiFwk.win-x64.<release>リリースごとに名前が変わる
PublisherId8wekyb3d8bbweMicrosoftのパッケージで使用される発行元ID

新しい分割構成では、HostパッケージがWindowsへの登録やMsTeamsVdi.exeの起動を担当し、Frameworkパッケージにメディアライブラリが格納されます。複数バージョンのFrameworkが同じエンドポイントに共存することもあります。(Microsoft Learn)

GPOでパッケージアプリの許可ルールを作成する

許可ルールは、VDIセッションホストではなく、接続元エンドポイントに適用されるGPOへ追加します。

  1. グループポリシー管理コンソールで対象GPOを編集します。
  2. 次の場所を開きます。
コンピューターの構成
  └ ポリシー
     └ Windowsの設定
        └ セキュリティの設定
           └ アプリケーション制御ポリシー
              └ AppLocker
                 └ パッケージアプリの規則
  1. 「パッケージアプリの規則」を右クリックします。
  2. 「新しい規則の作成」を選択します。
  3. アクションに「許可」を指定します。
  4. 対象ユーザーまたはグループを指定します。
  5. インストール済みパッケージアプリ、または入手したMSIXパッケージを参照します。
  6. SlimCoreのHost、Framework、または旧一体型パッケージを選択します。
  7. 必要な範囲まで規則を絞り込みます。
  8. 規則名に対象と用途が分かる名前を付けます。

規則名の例は次のとおりです。

Allow Microsoft Teams VDI SlimCore Host
Allow Microsoft Teams VDI SlimCore Framework

パッケージアプリのAppLocker規則では、発行元、パッケージ名、パッケージバージョンを基準に許可範囲を設定できます。更新に追随させるにはバージョンを固定しすぎないことが重要ですが、許可範囲を広げすぎないように注意してください。(Microsoft Learn)

HostとFrameworkではルール設計を分ける

Hostパッケージのパッケージファミリ名は固定されています。

Microsoft.Teams.SlimCoreVdiHost.win-x64_8wekyb3d8bbwe

そのため、Hostはパッケージ名単位で許可し、バージョン更新にも対応させやすい構成です。

一方、Frameworkや旧一体型SlimCoreでは、パッケージ名またはパッケージファミリ名にリリース番号が含まれます。

Microsoft.Teams.SlimCoreVdiFwk.win-x64.2026.20_8wekyb3d8bbwe

現在のFrameworkだけを厳密に許可すると、Teams更新後に新しいFrameworkがブロックされ、1260／10083が再発する可能性があります。

Microsoftは、AppLockerではこの用途で後方ワイルドカードを処理できないため、更新に追随させる場合はPublisherIdの8wekyb3d8bbweを基準としたAppX／MSIX除外を検討するよう案内しています。(Microsoft Learn)

ただし、8wekyb3d8bbweはSlimCoreだけに割り当てられたIDではなく、ほかのMicrosoft製パッケージでも使用されています。そのため、PublisherIdだけを基準に広く許可すると、SlimCore以外のパッケージにも許可範囲が広がる可能性があります。これはMicrosoftのパッケージ情報から判断できるため、セキュリティ部門と許可範囲を確認したうえで採用してください。(Microsoft Learn)

実務上の選択肢は次のようになります。

ルール設計更新への強さ許可範囲適した環境
HostとFrameworkを現在の名前で個別許可低い狭い更新を厳密に管理する環境
更新時にFramework規則を追加中程度狭いTeams更新前にGPOを更新できる環境
PublisherIdベースで許可高い広くなる可能性Evergreen更新を優先する環境
AppLockerを無効化高い制御なし原因切り分け用に限定

セキュリティを優先する環境では、Teamsの更新リングとAppLocker規則の更新を連動させる方法が適しています。運用負荷を抑えたい場合はPublisherIdベースを検討できますが、許可対象がSlimCoreだけに限定されない可能性を受け入れる必要があります。

明示的な拒否ルールがある場合は例外を修正する

AppLockerでは、明示的な拒否ルールが許可ルールより優先されます。

たとえば、既存の拒否ルールが次のような範囲をブロックしている場合、SlimCoreの許可ルールを追加するだけでは解決しません。

Microsoft発行の特定パッケージを拒否
すべてのパッケージアプリを拒否
特定グループに対してAppXを拒否

この場合は、拒否ルールを編集し、SlimCoreを例外として除外するか、拒否ルールそのものの対象範囲を狭めます。

判断方法は次のとおりです。

現在のブロック方式必要な修正
許可リストにSlimCoreがないSlimCoreの許可ルールを追加
明示的な拒否ルールがSlimCoreに一致拒否ルールへ例外を追加
GPOとローカルポリシーが競合有効ポリシーを確認して統合
GPOとMDM／CSPが競合Intuneなどの管理ポリシーも修正

「許可ルールを追加したのに直らない」というケースでは、明示的な拒否ルールの存在を最初に確認してください。(Microsoft Learn)

ルール追加後の反映と確認

AppLocker規則を変更したら、エンドポイントでポリシーを更新します。

gpupdate /force

有効なポリシーを再出力し、SlimCoreの規則が含まれていることを確認します。

Get-AppLockerPolicy -Effective -Xml |
    Set-Content C:\Temp\AppLocker-Effective-After.xml

その後、VDIクライアントとTeamsを再起動します。Teamsのメニューに「仮想デスクトップの最適化と再起動」が表示されている場合は、それを実行して再試行することもできます。(Microsoft Learn)

修正後は、次の項目を確認します。

  • Get-AppxPackage Microsoft.Teams.SlimCore*でHostまたはFrameworkが表示される
  • StatusがOkになっている
  • AppXDeploymentログに新しい0x800704ECが記録されない
  • AppLockerログに8025や8022が記録されない
  • Teamsの表示がSlimCore Media Not Connectedではなくなる
  • AVDではAVD SlimCore Media Optimizedと表示される
  • Vdi_debug.txtでremoteSlimcoreVersionが確認できる
  • connectedStackがremoteになっている

パッケージが正常に導入されても最適化されない場合は、AppLocker以外にVDIプラグイン、仮想チャネル、クライアントバージョンを確認します。(Microsoft Learn)

AppLockerを修正しても直らない場合の確認項目

1260／10083はAppLockerが代表的な原因ですが、ほかのポリシーでもMSIXインストールが阻害されることがあります。

状況次に確認する項目
AppLockerログに記録がないWDAC、App Control for Business、Code Integrity
Intune管理端末だけ失敗するAppLocker CSP、Application Controlポリシー
一般ユーザーだけ失敗するBlockNonAdminUserInstall
MSIX全般が失敗するAllowAllTrustedApps
15615も記録されるサイドローディング、信頼されたアプリのインストール
403が記録されるプロキシ、ファイアウォール、CDNアクセス
2000が記録されるVDIプラグインがない、または読み込まれていない
2003が記録されるCitrix仮想チャネル許可リスト
パッケージは存在するが起動しないAppLockerの実行規則、WDAC、パッケージ登録状態

新しいSlimCore MSIXのインストールに影響する可能性がある設定として、Microsoftは次の項目を挙げています。

BlockNonAdminUserInstall
AllowAllTrustedApps
AllowDevelopmentWithoutDevLicense
AppLocker
Windows Defender Application Control

AppLockerログに明確なブロックがない場合は、これらの設定を順番に確認してください。(Microsoft Learn)

よくある失敗

VDIセッションホストだけにGPOを適用する

SlimCore MSIXが導入されるのは接続元エンドポイントです。セッションホスト側だけを変更しても、エンドポイント側のAppLockerが残っていれば解決しません。

現在のFrameworkバージョンだけを許可する

Frameworkの名前にはリリース番号が含まれます。Teams更新後に新しいFrameworkが配信されると、再びブロックされる可能性があります。

許可ルールを追加すれば拒否ルールを上書きできると考える

AppLockerでは明示的な拒否が優先されます。拒否ルールに一致している場合は、そのルール側へ例外を追加する必要があります。

パッケージアプリ規則を1つだけ新規作成する

AppLockerの各規則コレクションは、基本的に明示的な許可リストとして動作します。未構成だったパッケージアプリ規則にSlimCoreの許可ルールだけを追加して適用すると、ほかのパッケージアプリが暗黙的にブロックされる可能性があります。

既存のAppLocker設計へ統合し、監査モードで影響を確認してから適用してください。(Microsoft Learn)

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

SlimCoreの存在確認を目的として、C:\Program Files\WindowsAppsの所有権やACLを変更するのは避けてください。Microsoftも、PowerShellでMSIXパッケージを列挙する方法を推奨しています。権限変更はほかのパッケージアプリやWindows更新に影響する可能性があります。(Microsoft Learn)

Application Identityサービスを止めるだけで無効化する

AppLockerの切り分けは、検証端末で規則コレクションを監査モードへ変更する方法が安全です。サービス停止だけでは有効ポリシーの状態が適切に更新されず、規則が残っているように見えるケースがあります。恒久的にAppLockerを解除する場合も、先に有効ポリシーを変更してからサービス構成を変更します。(Microsoft Learn)

まとめ

Teams VDI 2.0のエラー1260／10083と0x800704ECは、SlimCore MSIXのインストールがWindowsポリシーによって拒否されたことを示します。AppLockerが代表的な原因ですが、WDACやMSIX関連GPOも同様の問題を起こすため、イベントログによる確認が必要です。

対応は次の順序で進めます。

  1. VDIセッション内で1260／10083を確認する
  2. 接続元エンドポイントのAppXDeploymentログを確認する
  3. AppLockerの8022、8025、8021、8024を確認する
  4. 検証端末でパッケージアプリ規則を監査モードにする
  5. SlimCoreが導入できるか確認する
  6. HostとFrameworkに適した許可ルールを設計する
  7. 明示的な拒否ルールがあれば例外を追加する
  8. TeamsのVDI状態がSlimCore最適化へ戻ったことを確認する

最も重要なのは、AppLockerを全面的に無効化して終わらせるのではなく、接続元エンドポイントでSlimCore MSIXだけを適切に許可することです。

Teams
AppLocker MSIX SlimCore Teams VDI 0x800704EC

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次