Microsoft TeamsのVDI環境で通話品質や画面共有の遅延に悩んでいる場合、確認すべきポイントは「Teams本体の更新」だけではありません。New VDI solution for Teamsは、仮想デスクトップ上のTeamsの音声・ビデオ・画面共有を、エンドポイント側のSlimCoreメディアエンジンで処理する新しい最適化アーキテクチャです。導入時は、Teams、VDIクライアント、プラグイン、SlimCore MSIX、ネットワーク、GPO、セキュリティ制御をセットで確認する必要があります。(Microsoft Learn)
結論から言うと、New VDI solution for Teamsの移行は「有効化すれば終わり」ではなく、端末側にメディア処理をオフロードできる状態を作る作業です。Azure Virtual Desktop、Windows 365、Citrix、Amazon WorkSpaces、Omnissa Horizonで要件や制限が異なるため、管理者は対象ユーザーのVDI基盤ごとに展開計画を分けるべきです。開発者や運用担当者は、監視API、CQD、ログ、エンドポイント上のプロセス確認まで含めて、最適化状態を判定できる仕組みを用意しましょう。(Microsoft Learn)
New VDI solution for Teamsとは何か
New VDI solution for Teamsは、Microsoft TeamsをVDI環境で利用する際の音声、ビデオ、画面共有などのマルチメディア処理を最適化するための新しい仕組みです。従来のWebRTCベースの最適化に対し、新しい方式ではSlimCoreというメディアエンジンをエンドポイント側で動作させ、VDIセッション内のTeamsと連携してメディア処理を行います。(Microsoft Learn)
VDI環境では、Teamsを仮想マシン上で実行していても、実際のマイク、カメラ、スピーカー、ネットワーク接続はユーザーの手元の端末にあります。New VDI solution for Teamsは、この構造に合わせて、リアルタイムメディア処理を仮想マシン側ではなくエンドポイント側へ寄せる設計です。そのため、正しく動作すれば、仮想マシンのCPU負荷を抑えながら、会議や通話の品質改善が期待できます。
重要なのは、SlimCoreはVDIベンダー固有のメディアエンジンではなく、OS側・Teams側の構成と連動するコンポーネントとして扱われる点です。公式ドキュメントでは、Teams vdiBridge、カスタム仮想チャネル、クライアント側プラグイン、SlimCoreメディアエンジンという複数コンポーネントで構成されると説明されています。(Microsoft Learn)
何が変わるのか
New VDI solution for Teamsで最も大きく変わるのは、Teamsのメディア処理が「仮想デスクトップ内で完結する処理」ではなく、「仮想デスクトップ内のTeamsと、ユーザー端末側のSlimCoreが連携する処理」になることです。
| 変更点 | 旧来の考え方 | New VDI solution for Teamsでの考え方 |
|---|---|---|
| メディア処理 | WebRTCベースの最適化、または未最適化時はVM側負荷が増えやすい | SlimCoreメディアエンジンをエンドポイント側で動かす |
| 管理対象 | TeamsアプリとVDI基盤中心 | Teams、VDIクライアント、プラグイン、MSIX、GPO、ネットワークを一体で管理 |
| ネットワーク確認 | VM側通信だけを見がち | MsTeamsVdi.exeがエンドポイントからTeamsサービスへ通信する前提で確認 |
| トラブルシュート | Teamsログ中心 | VDI Status Indicator、Process Explorer、MSIX状態、Event Viewer、CQD、監視APIを併用 |
| ユーザー体験 | 端末やVDI基盤によって最適化状態が分かりにくい | Teams上でSlimCore最適化かWebRTC最適化かを確認しやすい |
公式ドキュメントでは、SlimCoreを使う新しい最適化により、1080p、エンドポイントでのハードウェアアクセラレーション、3×3/7×7ギャラリービュー、QoS、Presenter mode、Call Quality DashboardやTeams管理センターでの可視性など、従来のWebRTCベース最適化より広い機能が利用可能になるとされています。(Microsoft Learn)
ただし、すべてのVDI環境で同じ機能が使えるわけではありません。Macエンドポイント、Amazon WorkSpaces、RemoteAppやPublished App、タウンホール参加者などには制限があります。導入判断では「対応しているか」だけでなく、「自社の利用シナリオで必要な機能が最適化されるか」まで確認してください。(Microsoft Learn)
影響を受ける対象
New VDI solution for Teamsの影響範囲は、Teams利用者だけではありません。VDI基盤を管理するチーム、端末管理チーム、ネットワークチーム、セキュリティチーム、ヘルプデスク、監視ツールを作る開発者まで関係します。
| 対象者 | 確認すべきこと |
|---|---|
| Teams管理者 | CsTeamsVdiPolicy、ユーザー単位の有効・無効、会議機能の制限、CQDの見方 |
| VDI管理者 | AVD/Windows 365、Citrix、Amazon WorkSpaces、Omnissaごとの最小バージョンとプラグイン |
| 端末管理者 | Windows App、Citrix Workspace app、Horizon Client、WorkSpaces Client、Thin Client、Mac端末の要件 |
| ネットワーク管理者 | UDP/TCP疎通、Microsoft 365エンドポイント、QoS、VPNやプロキシの影響 |
| セキュリティ管理者 | AppLocker、WDAC、GPO、MSIXインストール制御、カメラ・マイク・位置情報の許可 |
| 開発者・運用自動化担当 | vdi_connection_info.json、Teamsログ、CQD、最適化状態の判定ロジック |
特に注意したいのは、エンドポイント側の制御です。仮想マシンのTeamsを更新しても、手元のWindows AppやCitrix Workspace appに必要なプラグインがなければ、SlimCore最適化は成立しません。Microsoftのトラブルシューティング情報でも、SlimCoreで最適化されない場合の代表的な原因として、プラグイン未検出や仮想チャネルのブロックが挙げられています。(Microsoft Learn)
対応VDI基盤と主な最小要件
公式情報では、Azure Virtual Desktop、Windows 365、Citrix、Amazon WorkSpaces、Omnissa Horizonが対象として整理されています。ただし、対応状況はVDI基盤やエンドポイントOSによって異なり、一部はPublic Previewです。主な最小要件は次のとおりです。(Microsoft Learn)
| 環境 | 主な確認ポイント |
|---|---|
| Azure Virtual Desktop / Windows 365 | Teams 24193.1805.3040.8975以降、Windows App for Windows 2.0.352.0以降。Remote Desktop Client for Windowsはサポートされなくなったため、最新のWindows Appへの移行が必要 |
| Citrix | Teams 24295.605.3225.8804以降、VDA 2203 LTSR CU3または2305 CR以降、Citrix Workspace appやMsTeamsPluginCitrixの要件確認が必要 |
| Amazon WorkSpaces | Teams 25198.1109.3837.4725以降、WorkSpaces Client 5.31.0.5733、WSP Server Agent 2.1.0.1840 |
| Omnissa Horizon | Teams 26032.206.4355.6508、Horizon Client for Windows 8.17以降。Public Preview扱い |
| Macエンドポイント | AVD/Windows 365およびCitrixでPublic Preview。非App Store版Windows AppやCitrix Workspace appのバージョン要件に注意 |
Windowsエンドポイントでは、SlimCoreの最小要件としてWindows 10 1809以降、Windows 10 LTSC 2019/2021またはWindows 11 2024のThin Client、最小CPU・RAM要件、MSIXインストールをGPOでブロックしないことなどが示されています。GPOやセキュリティ製品でMSIXを止めている環境では、Teamsのバージョンが条件を満たしていても最適化に失敗します。(Microsoft Learn)
管理者が最初に確認すべき設定
New VDI solution for Teamsを展開する前に、まず「対象ユーザーがどのVDI基盤・どの端末・どのクライアントでTeamsを使っているか」を棚卸ししてください。ユーザー単位で環境が混在している場合、全社一括展開よりも、VDI基盤ごとにパイロットを分けたほうが安全です。
Teamsポリシー
新しいSlimCoreベースの最適化は、CsTeamsVdiPolicyのVDI2Optimizationで制御できます。公式ドキュメントでは、VDI2Optimizationの既定値はEnabledで、VDIパートナー側のポリシーエンジンでは新しい最適化モードを制御しないと説明されています。(Microsoft Learn)
特定ユーザーだけ無効化したい場合は、たとえば検証用ポリシーを作成し、対象ユーザーへ割り当てます。
New-CsTeamsVdiPolicy -Identity RestrictedUserPolicy -VDI2Optimization "Disabled"
Grant-CsTeamsVdiPolicy -Identity "[email protected]" -PolicyName RestrictedUserPolicy既存ポリシーを変更する場合は、次のように設定します。
Set-CsTeamsVdiPolicy -Identity RestrictedUserPolicy -VDI2Optimization "Disabled"実務では、全社展開前に次の3グループを分けると判断しやすくなります。
| グループ | 目的 |
|---|---|
| パイロットユーザー | 代表的な端末・VDI基盤で最適化状態、通話品質、画面共有を確認 |
| 除外ユーザー | 互換性問題が出やすい周辺機器、特殊なThin Client、厳格なGPO環境を一時除外 |
| 本番展開ユーザー | 問題がない構成から順に段階展開 |
AVD / Windows 365の確認
Azure Virtual DesktopやWindows 365では、Windows Appへの移行が重要です。公式ドキュメントでは、Remote Desktop Client for Windowsはサポートされなくなったため、最新のWindows Appへアップグレードする必要があると記載されています。(Microsoft Learn)
また、AVDでTeamsのメディア最適化を使う場合、セッションホスト側のHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TeamsにIsWVDEnvironmentをDWORD値1で設定する手順がMicrosoft Learnに掲載されています。SlimCoreを使う場合でも、New TeamsとWindows AppまたはRemote Desktop clientに必要なコンポーネントがバンドルされる一方、WebRTCへのフォールバックも考慮する構成が案内されています。(Microsoft Learn)
New-Item -Path "HKLM:\SOFTWARE\Microsoft\Teams" -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Teams" -Name IsWVDEnvironment -PropertyType DWORD -Value 1 -ForceCitrixの確認
Citrixでは、仮想チャネルの許可リストが重要です。SlimCore最適化ではTeamsがカスタム仮想チャネルを使うため、古い構成のままだとプラグインがあっても接続できません。公式トラブルシューティングでは、Citrix StudioのVirtual Channel Allow listでMSTEAMS、MSTEAM1、MSTEAM2を許可する必要があるケースが示されています。(Microsoft Learn)
Citrix Workspace appのプラグイン導入は、UI、コマンドライン、SCCM、Intuneなどで実施できます。公式情報では、CitrixWorkspaceApp.exe /installMSTeamsPluginによるインストール、MSIの手動展開、プラグインはアクティブなVirtual Desktopセッションがない場合のみアップグレード可能で、ダウングレードはできないことが説明されています。(Microsoft Learn)
CitrixWorkspaceApp.exe /installMSTeamsPlugin本番展開では、CWA更新とプラグイン更新を同じメンテナンス枠で扱うのが安全です。ユーザーがVDIセッションを開いたまま更新すると、プラグイン更新が完了せず、翌日の問い合わせにつながる可能性があります。
Amazon WorkSpacesとOmnissa Horizonの確認
Amazon WorkSpacesでは最適化が一般提供されていますが、公式の既知の問題として、Share System Audio、アプリ共有、チャットからの画面共有がサポートされないとされています。会議で「コンピューター音声を含める」を多用する部署では、展開前に代替手順を案内してください。(Microsoft Learn)
Omnissa HorizonはPublic Previewとして扱われます。プレビュー環境では、ヘルプデスクの一次回答に「仕様」「既知の問題」「未対応」を切り分ける表を用意し、正式対応前に全社標準へ組み込まないほうが安全です。
SlimCore MSIXで失敗しやすいポイント
New VDI solution for Teamsの導入で最もつまずきやすいのは、SlimCore MSIXのステージングと登録です。プラグインは、ユーザーや管理者の手動操作なしにSlimCore MSIXをダウンロード・登録しますが、この処理はエンドポイントのApp Readiness ServiceやWindowsのパッケージアプリ制御に依存します。(Microsoft Learn)
公式ドキュメントでは、次のレジストリキーやポリシーがMSIXインストールをブロックする可能性があると説明されています。(Microsoft Learn)
| 確認項目 | 起きやすい問題 | 対応の方向性 |
|---|---|---|
| BlockNonAdminUserInstall | 非管理者ユーザーでSlimCore MSIXを登録できない | 許可対象PFNを設定、必要なWindows更新プログラムを適用 |
| AllowAllTrustedApps | 信頼済みアプリのインストールが無効になり失敗 | 組織ポリシーとWindows更新状態を確認 |
| AppLocker / WDAC | SlimCore関連のAppX/MSIX実行や登録をブロック | Publisher IDやPackage Family Nameで例外を設計 |
| GPO | パッケージアプリのインストール制限 | Teams VDI用の例外を端末管理ポリシーに反映 |
| UWF / RAM Disk | Thin ClientでMSIX登録やBITSダウンロードに失敗 | UWF除外、TEMP/TMPの物理ディスク退避を検討 |
新しいSplit MSIX Packageでは、HostパッケージとFrameworkパッケージに分かれます。許可リストを使う場合は、Microsoft.Teams.SlimCoreVdiHost.win-x64_8wekyb3d8bbweとMicrosoft.Teams.SlimCoreVdiFwk.*_8wekyb3d8bbweの両方を考慮する必要があります。(Microsoft Learn)
Thin ClientでUnified Write Filtersを利用している場合は、C:\Program Files\WindowsAppsやSlimCore関連パッケージのユーザーデータ領域を除外しないと、プロビジョニングや有効化に失敗する可能性があります。TEMP/TMPがRAM Diskを指している端末では、MSTEAMSVDI_BITS_TMP_PATHを物理ディスク上の一時フォルダーへ向ける回避策も示されています。(Microsoft Learn)
ネットワークとQoSで確認すべきこと
New VDI solution for Teamsでは、メディア通信を行う主体が重要です。公式ドキュメントでは、MsTeamsVdi.exeがTeamsのリレー、会議サーバー、他ピアへのTCP/UDP通信を行うプロセスだと説明されています。つまり、ネットワークチームは「仮想マシンからTeamsへ通信できるか」だけでなく、「ユーザー端末上のMsTeamsVdi.exeが必要なMicrosoft 365エンドポイントへ到達できるか」を確認する必要があります。(Microsoft Learn)
主な確認対象は、Microsoft 365のエンドポイントID 11、12、47、127、184です。TeamsのメディアではUDP 3478〜3481が重要で、SlimCoreダウンロードや背景効果、ノイズ抑制などに関連するエンドポイントもあります。Microsoft 365のURL/IP情報は更新されるため、固定表を社内資料に写すだけでなく、Microsoftの公開データやRSS、ネットワーク管理プロセスに組み込むのが安全です。(Microsoft Learn)
QoSを使う場合は、VDI内のTeamsプロセスではなく、エンドポイント側でメディアを処理するMsTeamsVdi.exeを対象にする点が重要です。公式情報では、音声、ビデオ、アプリまたは画面共有の推奨ポート範囲とDSCP値が示されています。(Microsoft Learn)
| メディア種別 | 推奨クライアント送信元ポート | プロトコル | DSCP値 |
|---|---|---|---|
| 音声 | 50000〜50019 | TCP/UDP | 46 |
| ビデオ | 50020〜50039 | TCP/UDP | 34 |
| アプリ共有・画面共有 | 50040〜50059 | TCP/UDP | 18 |
VPN、プロキシ、パケット検査、帯域制御装置は、Teamsのリアルタイムメディア品質を悪化させる要因になり得ます。特にVDIでは、端末からMicrosoft 365への直接経路が阻害されると、SlimCore化しても期待した品質改善が得られません。(Microsoft Learn)
最適化されているか確認する方法
展開後は、ユーザーの体感だけで判断せず、最適化状態を明示的に確認してください。Teamsクライアントでは、VDI Status IndicatorやSettings > Aboutで、SlimCoreベースの最適化か、従来のWebRTC最適化かを確認できます。たとえば、AVD SlimCore Media Optimizedは新しいSlimCoreベースの最適化、AVD Media Optimizedは従来のWebRTCベースの最適化を示します。(Microsoft Learn)
エンドポイント側では、PowerShellでSlimCoreパッケージを確認できます。
Get-AppxPackage Microsoft.Teams.SlimCore*Process Explorerを使う場合は、AVD/Windows 365ではmsrdc.exe配下、Citrixではwfica32.exe配下にMsTeamsVdi.exeが見えるか、またMsTeamsPluginAvd.dllやMsTeamsPluginCitrix.dllがロードされているかを確認します。公式ドキュメントでも、この確認は新しい最適化が得られない場合の有効なトラブルシューティング手順として示されています。(Microsoft Learn)
管理者や開発者は、VM上のvdi_connection_info.jsonも活用できます。このJSONには、現在および直近セッションの最適化状態、周辺機器、Teams、プラグイン、VDIクライアント、SlimCoreのバージョンなどが含まれます。ヘルプデスク用スクリプトや監視ダッシュボードを作る場合、このファイルを参照すれば「ユーザーがどの端末から、どの最適化状態で接続しているか」を機械的に判断できます。(Microsoft Learn)
C:\Users\<username>\AppData\Local\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams\tfwTeamsログを採取する場合は、VM上のTeamsでCtrl + Alt + Shift + 1を押してZIPログを生成し、VDI関連情報を確認します。接続エラーではloadErrcやdeployErrcが手掛かりになり、プラグイン未検出、仮想チャネル未許可、MSIX登録失敗、CDNダウンロード失敗などを切り分けられます。(Microsoft Learn)
移行・展開の実務手順
New VDI solution for Teamsを本番導入する場合は、次の順番で進めると失敗を減らせます。
| 手順 | 作業 | 成功条件 |
|---|---|---|
| 現状把握 | VDI基盤、端末OS、VDIクライアント、Teamsバージョン、利用周辺機器を棚卸し | 対象外・Preview・要更新端末を分類できている |
| 要件照合 | Microsoft公式の最小バージョンと社内標準イメージを比較 | 不足しているTeams、Windows App、CWA、プラグインが明確 |
| セキュリティ確認 | GPO、AppLocker、WDAC、MSIX、UWF、プロキシを確認 | SlimCore MSIXを登録・実行できる |
| ネットワーク確認 | Microsoft 365エンドポイント、UDP、QoS、VPN除外を確認 | 端末側のMsTeamsVdi.exeが必要通信を行える |
| パイロット展開 | 代表ユーザーで通話、会議、画面共有、周辺機器を検証 | Teams上でSlimCore最適化を確認できる |
| 監視設計 | CQD、vdi_connection_info.json、Teamsログ、Event Viewerを整備 | 問い合わせ時に原因を切り分けられる |
| 段階展開 | 部門・拠点・端末種別ごとに展開 | 未対応機能と回避策をユーザーへ案内済み |
特に画面共有は、事前検証が必要です。最適化されたVDIでは、画面共有やアプリ共有が通常のTeamsデスクトップクライアントと同じ挙動になるとは限りません。公式情報では、共有処理にユーザー端末のCPU、GPU、RAM、ネットワークが使われ、フルモニター共有ではTeamsの通話モニターが相手に見える一方、ビデオ要素は空白として見えることがあると説明されています。(Microsoft Learn)
AVDのScreen Capture ProtectionやCitrix App Protectionを使っている環境では、バージョン不足により黒い画面が共有されるケースがあります。セキュリティ機能を有効にしている組織ほど、Teams、VDIクライアント、保護機能の組み合わせを検証してください。(Microsoft Learn)
開発者・運用自動化担当が見るべきポイント
New VDI solution for Teamsは、Teamsアプリ開発者だけでなく、VDI運用ツールや監視スクリプトを作る開発者にも影響します。最適化状態の判定を画面表示やユーザー申告に頼るのではなく、vdi_connection_info.json、CQD、Teamsログを組み合わせて確認する設計にしましょう。
たとえば、ヘルプデスク向けに次のようなチェックを自動化できます。
$path = "$env:LOCALAPPDATA\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams\tfw\vdi_connection_info.json"
if (Test-Path $path) {
Get-Content $path | ConvertFrom-Json
} else {
Write-Output "VDI connection info not found. Teams may not be optimized or no VDI session data is available."
}このJSONには、vdiConnectedState.vdiMode、connectedStack、remoteSlimCoreVersion、bridgeVersion、pluginVersion、teamsVersion、clientPlatform、rdClientVersion、利用可能なスピーカー・カメラ・マイクなどが含まれます。WebRTC最適化時には一部情報だけが入り、最適化されていない場合はJSON更新がないこともあるため、「ファイルがない＝必ず異常」と短絡しない判定ロジックが必要です。(Microsoft Learn)
CQDを使う場合も注意が必要です。公式の既知の問題では、CQDのVdiMode値がSlimCore最適化と未最適化フォールバックの両方を表すことがあり、低品質の通話を誤ってSlimCore最適化の問題と解釈する可能性があるとされています。レポートでは、最適化有無を直接示すディメンションと組み合わせて判断してください。(Microsoft Learn)
既知の制限とユーザー案内のポイント
New VDI solution for Teamsは機能強化が大きい一方、制限もあります。展開前にユーザーへ伝えておくべきなのは、「新方式になったから何でも改善する」ではなく、「対応している機能は改善しやすいが、未対応のシナリオではフォールバックや制限がある」という点です。
| シナリオ | 注意点 |
|---|---|
| Macエンドポイント | Public Preview。HID、E2EE会議での送信画面共有、システム音声共有、RemoteApp/Published Appsなどに制限 |
| Amazon WorkSpaces | Share System Audio、アプリ共有、チャットからの画面共有はサポート外 |
| タウンホール参加者 | 最適化されず、サーバー側レンダリングとなりVMリソース消費が増えやすい |
| 音声・顔認識登録 | カメラやマイク選択に制限があり、VDIプロバイダー側のリダイレクトポリシー確認が必要 |
| 音量調整 | Teams最適化時、VM側のWindowsボリュームミキサーで制御できない場合がある |
| スクリーンショット | オフロードされたTeamsコンテンツが黒い四角としてキャプチャされる場合がある |
既知の問題として、カスタム背景の再アップロードが必要なケース、アプリ共有中のカーソルラグ、VMロック時の通話切断修正済みバージョン、Citrixでのアプリ共有フリーズなども挙げられています。ユーザー向けFAQには、「黒い画面になる」「マイクが選べない」「音量が変わらない」「画面共有でTeams通話画面が映る」といった問い合わせ例を先に用意しておくと、導入直後の混乱を抑えられます。(Microsoft Learn)
トラブル時の切り分け表
問い合わせが来たときは、最初に「SlimCore最適化されているか」「WebRTC最適化なのか」「未最適化フォールバックなのか」を切り分けます。
| 症状 | まず確認すること | よくある原因 |
|---|---|---|
TeamsにAVD Media OptimizedやCitrix HDX Optimizedと出る | SlimCoreではなくWebRTCで動作していないか | プラグイン未検出、初回検出後のTeams再起動不足 |
SlimCore Media Not Connectedと出る | MSIX登録、AppX、AppLocker、WDAC、GPO | SlimCore MSIXがインストールできない |
| Citrixで最適化されない | Virtual Channel Allow list | MSTEAMS、MSTEAM1、MSTEAM2が許可されていない |
| 通話品質が悪い | UDP疎通、VPN、プロキシ、QoS | 端末からTeamsメディア用エンドポイントへ直接到達できない |
| 画面共有が黒い | SCP/App Protection、TeamsとVDIクライアントのバージョン | 保護機能とバージョンの組み合わせ不備 |
| Thin Clientで失敗する | UWF、RAM Disk、TEMP/TMP、BITS | MSIXダウンロードや登録が保持されない |
公式トラブルシューティングでは、エラーコード2000はプラグインなし、2003はCitrixのカスタム仮想チャネルがポリシーでブロック、1260/10083はポリシーによるMSIXインストール無効化、403/3227はSlimCore MSIXダウンロードがネットワークやプロキシでブロックされている可能性があると整理されています。(Microsoft Learn)
導入前に決めておくべき運用ルール
New VDI solution for Teamsを安定運用するには、技術設定だけでなく運用ルールが必要です。最低限、次の4つは展開前に決めておきましょう。
| 運用ルール | 決める内容 |
|---|---|
| バージョン管理 | Teams、Windows App、CWA、プラグイン、Horizon Client、WorkSpaces Clientの更新基準 |
| 例外管理 | SlimCoreを一時的に無効化するユーザー、端末、VDI基盤の条件 |
| 問い合わせ導線 | ユーザーがVDI Status Indicator、TeamsのAbout、端末種別を報告する手順 |
| 監視・品質管理 | CQD、vdi_connection_info.json、Teamsログ、Event Viewerを誰が確認するか |
おすすめは、最初から「全員をSlimCoreへ移す」ではなく、「品質改善効果が大きい部署」から展開することです。具体的には、Teams会議が多いコールセンター、営業、サポート、オンライン研修部門などです。一方で、特殊なThin Client、厳格なAppLocker/WDAC、古いCitrix構成、Mac中心の部門は後回しにすると、初期トラブルを減らせます。
New VDI solution for Teamsは、VDI環境のTeams体験を改善する有力な選択肢です。ただし成功条件は、Teamsアプリの更新ではなく、エンドポイント側でSlimCoreを正しく動かし、必要な通信とポリシーを許可し、最適化状態を継続的に確認できることです。まずは代表端末でTeamsのバージョン、VDIクライアント、プラグイン、MSIX、ネットワーク、GPOをチェックし、パイロット展開でSlimCore Media Optimizedを確認してから本番展開へ進めてください。
コメント