MENU

Teams VDIエラー110の解決方法｜BITSバックグラウンド制限を解除

Teams

Microsoft Teams VDI 2.0でERROR_OPEN_FAILED 110が発生し、SlimCoreを取得できない場合は、接続元Windows端末のバックグラウンドアプリ設定を最初に確認します。

AVDやWindows 365をWindows Appから利用している環境では、WindowsのバックグラウンドアクセスポリシーによってBITSが遮断され、SlimCore MSIXのダウンロードに失敗することがあります。まずWindows Appの「このアプリをバックグラウンドで実行する」を「常に」に変更してください。設定項目が表示されない場合は、接続元端末のGlobalUserDisabledを確認し、値が1なら0へ変更します。(Microsoft Learn)

目次

Teams VDIエラー110で最初に行うこと

Teams VDIエラー110の基本的な対処順序は、次のとおりです。

順序確認・対処内容
1Teamsログで110とERROR_OPEN_FAILEDを確認する
2接続元端末のWindows Appをバックグラウンド実行「常に」にする
3項目がない場合はGlobalUserDisabledを確認する
4GPOやIntuneでバックグラウンド実行が強制拒否されていないか確認する
5Windows AppとTeamsを再起動し、ログを再取得する

重要なのは、設定を変更する場所がAVDやWindows 365のセッションホストではなく、Windows Appを実行している接続元端末であることです。

ERROR_OPEN_FAILED 110が示す原因

Teams VDI 2.0の新しい最適化では、接続元端末のプラグインがMicrosoftのCDNからSlimCore MSIXパッケージを取得します。その後、AppXのApp Readiness Serviceを使って、パッケージのステージングや登録が行われます。

Teamsのログでは、主に次の2種類のエラーを確認します。

エラーの種類発生する処理
デプロイエラーSlimCore MSIXのダウンロード、ステージング、登録
ロードエラーMsTeamsVdi.exeの起動、RPC接続の確立

エラー110は、WindowsのバックグラウンドアクセスポリシーがBITSをブロックしている状態を表します。内部的にはBG_E_BLOCKED_BY_BACKGROUND_ACCESS_POLICYとして扱われ、SlimCoreのダウンロードが進まなくなります。(Microsoft Learn)

ERROR_OPEN_FAILEDという名称だけで判断しない

ERROR_OPEN_FAILEDという名前から、ファイル破損やアクセス権不足を疑いたくなります。しかし、Teams VDI 2.0のエラー110では、実際の原因がBITSのバックグラウンド実行制限である場合があります。

そのため、次の対処を先に行っても解決しない可能性があります。

  • Teamsの再インストール
  • AVDセッションホスト上のTeamsキャッシュ削除
  • Microsoft CDNへの通信許可だけを確認する
  • BITSサービスを手動で何度も再起動する
  • SlimCore MSIXを手作業で展開する

ログに110が記録されている場合は、ネットワーク調査より先にWindows Appのバックグラウンド実行許可を確認するのが効率的です。

修正する端末を間違えない

AVD・Windows 365環境では、Teamsが動くセッションホストと、Windows Appが動く接続元端末が分かれています。

確認項目確認する場所
Windows Appのバックグラウンド実行設定接続元のWindows端末
GlobalUserDisabledレジストリ接続元端末の対象ユーザー
BITSによるSlimCoreダウンロード接続元端末
Teamsのvdi_debug.txtAVD・Windows 365上のTeams
Microsoft Teams VDIイベントセッションホストVM
AppXDeploymentServerイベント接続元端末

特に注意したいのが、GlobalUserDisabledはHKCU配下にある点です。管理者アカウントで別ユーザーとしてレジストリエディターやPowerShellを実行すると、障害が発生しているユーザーとは別のプロファイルを変更してしまうことがあります。

原則として、実際にWindows Appを利用しているユーザーのコンテキストで確認してください。

Teamsログでエラー110を確認する

設定を変更する前に、本当にエラー110が発生しているか確認します。

Teamsログの取得手順

  1. AVDまたはWindows 365のセッション内でTeamsを起動します。
  2. 問題を再現します。
  3. Teamsを開いた状態でCtrl＋Alt＋Shift＋1を押します。
  4. ダウンロードフォルダーに作成されたPROD-WebLogs-*.zipを展開します。
  5. ZIP内のCoreフォルダーを開きます。
  6. vdi_debug.txtやDiagnostics-logs.txtを確認します。
  7. 次の文字列を検索します。
110
ERROR_OPEN_FAILED
BG_E_BLOCKED_BY_BACKGROUND_ACCESS_POLICY
loadErrc
deployErrc

Microsoftの資料では、Teams VDIの接続エラーはloadErrcとdeployErrcを含むログ行から確認するよう案内されています。(Microsoft Learn)

「Azure Virtual Desktop SlimCore Media Not Connected」と表示されているだけでは、エラー110とは断定できません。プラグイン未検出、AppLocker、MSIXインストール制限、タイムアウトなどでも同様の状態になるため、必ずエラーコードまで確認します。

Windows Appのバックグラウンド実行を「常に」にする

エラー110を確認できたら、Windows Appを実行している接続元端末で設定を変更します。

設定アプリから変更する手順

  1. 接続元端末で「設定」を開きます。
  2. 「アプリ」を選択します。
  3. 「インストールされているアプリ」を開きます。
  4. 一覧から「Windows App」を探します。
  5. 右側の「…」を押します。
  6. 「詳細オプション」を選択します。
  7. 「バックグラウンドアプリのアクセス許可」を確認します。
  8. 「このアプリをバックグラウンドで実行する」を「常に」に変更します。

Windowsのビルドや表示言語によっては、次の経路から設定する場合もあります。

設定
  └ システム
      └ 電源とバッテリー
          └ バッテリーの使用状況
              └ Windows App
                  └ バックグラウンドアクティビティの管理

Windowsのバックグラウンド実行設定には「常に」「電力最適化」「なし」などがあります。「電力最適化」ではWindows側の判断で実行が制限される可能性があるため、エラー110の切り分けでは「常に」を選択します。(マイクロソフトサポート)

設定後はWindows Appを完全に終了し、再度起動してAVDまたはWindows 365へ接続します。

設定項目が表示されない場合はGlobalUserDisabledを確認する

Windows Appの詳細オプションにバックグラウンド実行の項目が表示されない場合は、次のレジストリを確認します。

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\BackgroundAccessApplications

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

GlobalUserDisabled

Microsoftは、GlobalUserDisabledが1の場合は0へ変更するよう案内しています。(Microsoft Learn)

PowerShellで確認する

接続元端末で、対象ユーザーとしてPowerShellを開き、次のコマンドを実行します。

$path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\BackgroundAccessApplications'

Get-ItemProperty `
    -Path $path `
    -Name 'GlobalUserDisabled' `
    -ErrorAction SilentlyContinue |
    Select-Object GlobalUserDisabled

結果が次のようになった場合は、バックグラウンドアプリがグローバルに無効化されています。

GlobalUserDisabled
------------------
1

値が1の場合に0へ変更する

$path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\BackgroundAccessApplications'

Set-ItemProperty `
    -Path $path `
    -Name 'GlobalUserDisabled' `
    -Value 0

確認から変更までをまとめて実行する場合は、次のスクリプトを使用できます。

$path = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\BackgroundAccessApplications'

$value = Get-ItemPropertyValue `
    -Path $path `
    -Name 'GlobalUserDisabled' `
    -ErrorAction SilentlyContinue

if ($value -eq 1) {
    Set-ItemProperty `
        -Path $path `
        -Name 'GlobalUserDisabled' `
        -Value 0

    Write-Host 'GlobalUserDisabledを1から0へ変更しました。'
}
elseif ($value -eq 0) {
    Write-Host 'GlobalUserDisabledはすでに0です。'
}
else {
    Write-Host 'GlobalUserDisabledは未構成です。'
}

変更後は、次の順番で再確認します。

  1. Windowsからサインアウトして再度サインインするか、端末を再起動します。
  2. Windows Appの詳細オプションを開きます。
  3. バックグラウンド実行を「常に」にします。
  4. Windows Appを再起動します。
  5. AVDまたはWindows 365へ再接続します。
  6. Teamsを再起動します。

GlobalUserDisabledを0にしただけでは、Windows App固有の設定が「常に」になっていない場合があります。レジストリ変更後も、Windows Appの詳細オプションを再確認してください。

GPOやIntuneで強制拒否されていないか確認する

企業管理端末では、ユーザーがレジストリを変更しても、グループポリシーやIntuneによって設定が再適用されることがあります。

次のような場合は管理ポリシーを確認します。

  • バックグラウンド実行の項目がグレーアウトしている
  • GlobalUserDisabledを変更しても元に戻る
  • 複数の端末で同じエラー110が発生する
  • 特定の構成プロファイルを適用した端末だけで発生する
  • Windows Appを「常に」に変更できない

グループポリシーの確認場所

コンピューターの構成
  └ 管理用テンプレート
      └ Windowsコンポーネント
          └ アプリのプライバシー
              └ Windowsアプリのバックグラウンド実行を許可する

「すべてのアプリの既定値」が「強制的に拒否」になっている場合は、Windows Appのバックグラウンド処理も制限される可能性があります。

Intuneで確認するポリシー

Policy CSPでは、次の設定がバックグラウンド実行を制御します。

./Device/Vendor/MSFT/Policy/Config/Privacy/LetAppsRunInBackground

主な値は次のとおりです。

| 値 | 動作 |
| – | ——- |
| 0 | ユーザーが制御 |
| 1 | 強制的に許可 |
| 2 | 強制的に拒否 |

MicrosoftのPolicy CSPには、アプリごとの強制許可リストと強制拒否リストも用意されています。全アプリを一律に許可するより、組織のセキュリティ方針に応じてWindows Appだけを例外化する方法を検討した方が安全です。(Microsoft Learn)

ローカルレジストリだけを変更しても再びエラーが発生する場合は、Intuneの構成プロファイル、セキュリティベースライン、GPO、端末構築スクリプトを確認してください。

修正後にSlimCore接続を確認する

設定変更後は、Windows AppとTeamsを再起動し、Teamsログをもう一度取得します。

正常な状態では、次の組み合わせが確認できます。

loadErrc=0
deployErrc=0

0 / 0はSlimCore Connectedの成功状態です。また、次のコードはエラーではなく、新しいSlimCore最適化アーキテクチャで動作していることを示す場合があります。

コード意味
3000 / 24002SlimCoreのデプロイが不要
3001 / 24010SlimCoreがすでに読み込まれている

一方、connectedStack: remoteだけで正常と判断するのは避けてください。これは仮想チャネル経由でリモートエンドポイントへ接続できたことを示しますが、通話スタックの初期化まで成功したとは限りません。エラーコード、remoteSlimcoreVersion、実際の通話テストを合わせて確認します。(Microsoft Learn)

エラー110が消えてもSlimCoreを取得できない場合

設定変更後に別のエラーコードへ変わった場合は、原因も変わっています。同じBITS対策を続けるのではなく、新しいコードに応じて切り分けます。

エラーコード主な原因確認内容
110BITSのバックグラウンドアクセスポリシーWindows App、GlobalUserDisabled、GPO、Intune
403 / 3227CDN通信が拒否されているプロキシ、ファイアウォール、URLフィルター
404 / 3235SlimCore MSIXを取得できないプロキシ干渉、パッケージ公開状態
1260 / 10083アプリの実行・インストールがポリシーで禁止AppLocker、アプリ制御ポリシー
2000 / 16002VDIプラグインがない、または読み込まれていないWindows App、プラグイン、クライアント更新
3005 / 240432分以内にMSIXをダウンロードできない回線速度、プロキシ、CDN通信
3007 / 24058ダウンロードまたはインストールのタイムアウト通信速度、App Readiness Service
15615 / 1951SlimCore MSIXのインストールポリシー違反AllowAllTrustedApps、サイドローディング設定

Microsoftのトラブルシューティング資料でも、403はネットワークやプロキシ、1260はAppLocker、15615はMSIXインストールポリシーとして区別されています。(Microsoft Learn)

イベントビューアーで追加確認する

Teamsログだけで原因を特定できない場合は、セッションホストと接続元端末の両方でイベントを確認します。

セッションホストVMで確認するログ

イベントビューアー
  └ Windowsログ
      └ アプリケーション

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

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

接続元端末で確認するログ

イベントビューアー
  └ アプリケーションとサービスログ
      └ Microsoft
          └ Windows

次のログを確認します。

AppxPackagingOM
  └ Microsoft-Windows-AppxPackaging/Operational

AppXDeployment-Server
  └ Microsoft-Windows-AppXDeploymentServer/Operational

エラー110が解消した後にAppXやMSIX関連のエラーが残る場合は、SlimCoreのダウンロードには成功したものの、ステージングや登録処理で失敗している可能性があります。(Microsoft Learn)

よくある失敗と注意点

AVDセッションホスト側だけを変更する

Windows Appのバックグラウンド設定とGlobalUserDisabledは、基本的に接続元端末で確認します。セッションホストの同名レジストリを変更しても、接続元端末のBITS制限は解除できません。

PowerShellを別の管理者アカウントで実行する

HKCUは、コマンドを実行しているユーザーのレジストリです。管理者の資格情報で別プロセスを起動すると、障害ユーザーではなく管理者側の設定を変更する可能性があります。

「電力最適化」のままにする

「電力最適化」は完全な許可ではありません。Windowsの判断でバックグラウンド動作が制限される場合があるため、エラー110の対処では「常に」を選択します。

GlobalUserDisabledだけを変更して完了とする

GlobalUserDisabledを0にしても、Windows App個別の設定が「常に」になるとは限りません。レジストリ変更後にGUI設定を再確認します。

IntuneやGPOを確認せずローカル設定だけを直す

管理ポリシーが原因の場合、端末の再起動やポリシー同期によって設定が元に戻ります。複数端末で再発する場合は、個別修正ではなく配布ポリシーを修正します。

エラーコードが変わってもBITSだけを調査する

110から403、1260、15615などへ変化した場合、BITS制限は解消している可能性があります。新しく記録されたコードに沿って、ネットワーク、AppLocker、MSIXポリシーへ調査対象を切り替えます。

Teams VDIエラー110の対処手順まとめ

Teams VDI 2.0のERROR_OPEN_FAILED 110は、接続元Windows端末でBITSのバックグラウンド通信が制限され、SlimCore MSIXを取得できないときに発生することがあります。

次の順番で対処すると、原因を効率よく切り分けられます。

  1. Teamsログでエラー110を確認する
  2. 接続元端末のWindows Appをバックグラウンド実行「常に」にする
  3. 項目がない場合はGlobalUserDisabledを確認する
  4. 値が1なら0へ変更する
  5. GPOやIntuneのLetAppsRunInBackgroundを確認する
  6. Windows AppとTeamsを再起動する
  7. ログを再取得し、loadErrc=0とdeployErrc=0を確認する
  8. 別のコードが出た場合は、そのコードに応じて調査対象を切り替える

特にAVD・Windows 365では、「セッションホストではなく、Windows Appが動作している接続元端末を修正する」という点が最も重要です。

Teams
BITS Windows 365 Azure Virtual Desktop SlimCore Teams VDI

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次