相手の Windows PC でサポートセッションを開始する必要があります。相手は「このファイルをダウンロードしてください」という言葉を聞くと黙り込んでしまいます。以下では、リモート側にインストール不要でセッションを開始する方法、それに対応できる Windows のツール、それぞれがどこでつまずくか、そして私が確認済みの対処法を示します。
ネイティブな方法がいずれも合わない場合は、HelpWire はクライアント側でインストール不要でセッションを開始できるリモートサポートソフトウェアです。セッションを開始するための専用の接続リンクをクライアントに送信してください。クライアントはポータブルアプリを実行してあなたにアクセスを許可するだけで参加でき、インストーラーもアカウントも認証情報も不要です。
RDP をネイティブに使用してリモートサポートセッションを開始する方法
対象でリモート デスクトップが有効になっていれば、mstsc.exe でネイティブ セッションを開始できます。手順は、クライアント側・サーバー側のどちらにも何もインストールせずに4つのステップで完了します。mstsc.exe と リモート デスクトップ サービス は、どちらも既に Windows に同梱されています。
-
対象のマシンで、
SystemPropertiesRemote.exeを実行し、このコンピューターへのリモート接続を許可する を選択するか、設定、システム、リモート デスクトップ を使用します。レジストリでの同等設定は、HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server配下のfDenyTSConnectionsを0に設定することです。 -
services.mscを開き、リモート デスクトップ サービス (サービス名TermService) が実行中であることを確認します。 -
管理者権限の PowerShell プロンプトからファイアウォール グループを有効にします。Microsoft の接続失敗に関する記事では、この
コマンドレットが示されています:Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Set-NetFirewallRule -Enabled True -
お使いのマシンから、リスナーが応答することを確認後、接続します:
Test-NetConnection -ComputerName PC01 -Port 3389mstsc.exe /v:PC01
手順 4 で 0x204 のエラー コードが Remote access to the server is not enabled というテキストとともに返された場合は、DNS、NLA、または RD ゲートウェイのようなより限定的な原因の調査に進む前に、リモート デスクトップの有効化、TermService、ファイアウォール ルール、および基本的なネットワーク到達性を再確認してください。
RDP 経由で接続すると、ユーザーの画面はどうなりますか
ローカル ユーザーは対話型デスクトップから切断されます。これは、通常の RDP を立会いサポートに適さないものにしている唯一の挙動であり、誤設定ではなく設計によるものです。
仕組み: mstsc.exe は対象マシンで新しいログオン セッションを要求します。Windows のデスクトップ エディションでは、対話型セッションは同時に 1 つだけ許可されます。Windows はコンソール セッションをロックまたは切断し、ローカルの表示はロック画面に切り替わります。あなたのセッションはクライアント ウィンドウ内にのみ表示されます。ユーザーがキーボードで再度サインインすると、代わりにあなたのセッションが切断されます。
Microsoft Learn のスレッドの回答者は、これを端的に述べています: RDP はリモート ホスト上で独自のセッションを開始し、すべてが共有される VNC 方式のツールとは異なり、それはあなたのクライアントにのみ表示されます。質問者は、ローカル ユーザーがログアウトされたことを確認し、その挙動を相互排他的だと表現しました。同じマシンを二人で取り合うと、そのうちの一方には Another user is signed in. If you continue, they’ll be disconnected. Do you want to sign in anyway? と表示されます。
リモートサポートにおけるRDPの制限事項
RDP はリモートアクセスを解決しますが、リモート アシスタンスは解決しません。これらは要件の異なる別々の問題であり、そのギャップはサポート業務ですぐに明らかになります。
制限事項:
• Home エディションはホストできません。 Microsoft は、受信側の RDP ホスティングは Pro, Enterprise、および Education に限定されると明記しています。
• インタラクティブ セッションは1つのみ。あなたが接続した瞬間にコンソール ユーザーは切断されます。
• 画面共有はありません。あなたが見ているのは別のデスクトップのため、ユーザーが説明しているエラーダイアログは見られません。
• 同意プロンプトはありません。標準の RDP は、キーボードの前にいる人に承認を求めるのではなく、認証と認可でアクセスを制御します。
• NAT を越える経路はありません。ポート 3389 は VPN かポート転送が必要で、家庭用 PC に 3389 を転送すると、自動スキャンやパスワード攻撃にさらされます。
• チャットも、操作権を戻す方法もありません。並行して電話をつないでおく必要があります。
大半の人が最初に試すことと、なぜそれが失敗するのか
フォーラムのスレッドでは五つの回避策が大勢を占めているが、そのどれもRDPをサポートツールに変えるものではない。
同時セッションのためにTerminal Servicesにパッチを当てるのが最も一般的だ。だが期待どおりには動作しない。rdpwrap リポジトリの GitHub issue 1141 では、Windows 10 Pro ビルド 19041.264 を実行しているユーザーが RDPConf であらゆるインジケーターが緑だと報告した一方で、別のユーザーは依然として Another user is signed in を受け取っている。
バイナリパッチはさらに悪い。誰かがビルド 19044.1766 上の termsrv.dll バージョン 10.0.19041.1741 に固定された TermsrvPatcher のバイトパターンを投稿しており、これは次の累積更新でその DLL が書き換えられるまでパッチが持続することを意味する。同時ログオンがうまくいったとしても、得られるのは共有デスクトップではなく二つの別々のデスクトップだ。
両方のマシンでファイアウォールを無効にするのが二つ目だ。ある Microsoft Q&A の投稿者は両システムであらゆるWindowsファイアウォールをオフにし、対象の Administrators グループに自分のアカウントを追加したが、それでも Access denied に遭遇した。失敗は資格情報およびRPCに関連していたため、パケットフィルタリングを外しても何も変わらなかった。
443 に加えてRPCレンジを開放するのが三つ目だ。Windows OS Hub のスレッドの読者が、両方のマシンで 443 と 49152 から 65535 を開けたが、それでも This computer name is invalid を受け取った。
コマンド内でRPCポートを固定するのが四つ目だ。Mstsc.exe /control /shadow:1 /v:remotepcname:56772 を実行しても同じ無効なコンピューター名エラーが返され、サイトの著者はコメントで、シャドウ接続用にRPCポートを固定する既知の方法はないことを確認している。
設定、アプリ、オプション機能からQuick Assistを再インストールするのが五つ目の対処だ。これは Quick Assist がオプション機能のままであるビルドにのみ適用される。Microsoft は組み込みアプリを廃止して Microsoft Store に移行したため、現在のビルドではこの方法はどこにもつながらない。
確認済みの修正 1: 管理しているマシンの RDP シャドウイング
シャドウイングは、既存のユーザーセッションを置き換えるのではなくそれに接続し、これが標準的なmstsc接続との相違点です。これは Windows 8.1 およびServer 2012 R2以降で動作します。ユーザーは自分のデスクトップを保持し、同意プロンプトが表示され、あなたのカーソルが動くのを見ます。以下の手順は、Microsoft が文書化しているシャドウイングの制御に、Microsoft Q&A、Windows OS Hub のコメントスレッド、および tinyapps の再現可能な解説で動作が報告されている構成を組み合わせたものです。
-
対象が Pro、Enterprise、または Education を実行していることを確認し、上のネイティブ RDP セクションの手順 1~3 に従ってリモート デスクトップを有効にします。シャドウイングは Remote Desktop Services サービスに依存しているため、
TermServiceが停止しているか利用できない場合、シャドウイングは失敗します。この状況で報告されるエラーの一つは次のとおりです:The version of Windows running on this server does not support user shadowing。 -
明示的に リモート デスクトップ サービス の権限を委任している場合を除き、対象マシン上でお使いのアカウントにローカル管理者権限を付与してください。いずれか一方がない場合、手順 6 のセッション クエリは、
mstscを起動する前に失敗します。 -
シャドウ ポリシーを設定します。グループ ポリシー: Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, Remote Desktop Session Host, Connections、
Set rules for remote control of Remote Desktop Services user sessions。レジストリ経由:reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v Shadow /t REG_DWORD /d 1値
0はシャドウを無効にします。1はユーザーの許可ありのフル コントロール。2は許可なしのフル コントロール。3は許可ありの表示のみ。4は許可なしの表示のみ。有人サポートの場合は、コンピューターが継承するものに頼るのではなく、値を明示的に1に設定してください。 -
対象でリモート RPC を許可し、その後再起動してください。コミュニティからの報告では、再起動を省略することが手順 6 でアクセス拒否が返される最も一般的な理由であり、テストでは、その値はマシンを再起動するまで有効になりませんでした。
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v AllowRemoteRPC /t REG_DWORD /d 1 -
対象で両方のファイアウォール ルールを有効にします。ここで検証した構成では、シャドウイングには File and Printer Sharing (SMB-In) と Remote Desktop – Shadow (TCP-In) のルールを有効にし、
3389ポート単体ではなく、139/TCP、445/TCP、および49152から65535までの動的 RPC 範囲のトラフィックを許可する必要がありました。RPC 範囲のうちどこまで開放する必要があるかは両マシン間のネットワークに依存します。そのため、mstsc接続が機能していても、シャドウイングが接続できることの証明にはなりません。Enable-NetFirewallRule -DisplayName "File and Printer Sharing (SMB-In)"Enable-NetFirewallRule -DisplayName "Remote Desktop - Shadow (TCP-In)"2 つ目のルールは、シャドウ エージェント プロセスである
RdpSa.exeへのリモート アクセスを許可するものです。どちらのルールもプロファイルに依存します。SMB と RPC に到達可能だとみなす前に、設定, ネットワークとインターネット, の下で対象のアクティブなネットワーク プロファイルを確認し、有効化したルールが使用中のプロファイルをカバーしていることを確認してください。 -
ローカルアカウントと対象アカウントが一致しない場合は資格情報をキャッシュし、次にセッション ID を読み取ります:
cmdkey /add:PC01 /user:PC01\admin /passqwinsta /server:PC01物理キーボードの前にいるユーザーは、
SESSIONNAMEが console と表示され、ほとんどの場合 ID は 1 です。 -
セッションに接続する:
mstsc.exe /shadow:1 /v:PC01 /control
ユーザーには、PC01\admin がリモートであなたのセッションの表示を要求しています。要求を承諾しますか? と表示されます。承諾すると、ウィンドウのタイトルは 表示中 から 操作中 に変わります。
閲覧専用セッションにするには /control を外します。/noConsentPrompt スイッチも存在し、Shadow の値 2 または 4 が必要ですが、有人対応の作業ではそのままにしておきます。というのも、同意プロンプトだけがユーザーに技術者が画面上にいることを知らせる唯一のものだからです。
フラグを選ぶ前に知っておくべき挙動が1つあります。/control なしで接続すると、セキュア デスクトップに UAC プロンプトが表示されるたびにシャドウ ウィンドウは一時停止記号の付いた黒い画面になり、ユーザーが応答するとセッションは再開します。/control を付けると、UAC プロンプトはセッション内に表示されるため、あなた自身で資格情報を入力できます。どちらにするかのフラグが、シャドウイングが管理者権限への昇格を処理するのか、それともそこで停止するのかを決めます。
RDP シャドウイングのエラーメッセージと解決策
これらの6つのエラー文字列は、Microsoft Q&A やコミュニティ スレッドで報告されている一般的なシャドウイングの失敗をいくつか網羅しており、それぞれにまず確認すべき可能性の高い原因があります。
| エラー文字列 | 一般的な原因 | 確認済みの修正 |
Shadow Error: This computer name is invalid |
Shadow のファイアウォール ルールが無効、または RPC に到達できない | 有効にする File and Printer Sharing (SMB-In) および Remote Desktop - Shadow (TCP-In)、動的 RPC を開放し、49152 から 65535 |
Shadow Error: Access is denied |
ローカルとリモートの資格情報が異なる | cmdkey で資格情報をキャッシュする、または /prompt を mstsc コマンドに追加する |
Shadow Error: The session identification does not specify a valid session |
誤ったセッション ID が /shadow に渡された: |
query user または qwinsta /server で ID を再確認する |
Error [5]: Access is denied (returned by qwinsta) |
qwinsta には /prompt に相当するものがないため、資格情報はあらかじめ一致している必要がある |
クエリを実行する前に cmdkey で資格情報をキャッシュする |
ERROR 1722 RPC server is unavailable |
AllowRemoteRPC が設定されていない、または RPC エンドポイントがブロックされている |
AllowRemoteRPC を 1 に設定し、再起動して、135 および 445 に到達可能であることを確認する |
The version of Windows running on this server does not support user shadowing |
TermService が停止または無効になっている、あるいは対象が Home エディションで動作している |
リモート デスクトップ サービス を開始する。対象が Home の場合はここで中止する |
すべての設定が正しく見えるのに接続がタイムアウトする場合は、WOSHub のコメント投稿者が提示し、複数の人が確認した次の手順を実行してください: 設定でリモート デスクトップをいったんオフにしてからオンにし、現在のネットワーク プロファイルでファイルとプリンターの共有を有効にし、その後 services.msc で Remote Desktop Services を再起動します。これにより古いリスナー状態がクリアされ、所要時間は30秒ほどです。
確認済みの修正 2: あなたが管理していないデバイス向けのクイック アシスト
クイック アシストは、インターネット経由での有人サポートのための Microsoft の現行のネイティブ ツールであり、支援を受ける側はサインインする必要がありません。Microsoft のドキュメントでは、どちらの当事者もドメインに属している必要はないことが確認されており、支援する側は Microsoft アカウントまたは Entra ID でサインインします。ローカルの Active Directory 認証はサポートされていません。
-
お使いの PC で、
Ctrl + Windows + Qを押すか、スタート から クイック アシスト を検索して、サインインします。 -
支援を行う をクリックし、有効期限付きのコードをユーザーに読み上げてください。
-
ユーザーは クイック アシスト、 を開き、コードを入力し、画面共有を開始するために 許可 をクリックします。
-
制御を要求をクリックします。入力できるようになる前に、ユーザーは2回目のプロンプトを承認します。
ファイアウォールを越えられる理由は設計によるものです。Quick Assist は Microsoft の Remote Assistance Service と HTTPS の 443 で通信し、その中に RDP を載せているため、ポートフォワーディングも VPN も不要で、受信規則を作成する必要もありません。
制限事項:
• 管理対象デバイスでは組織のポリシーによりストアからのダウンロードがブロックされる場合があり、これはインストール ページで Microsoft が文書化しています。
• Microsoft Edge WebView2 が必要です。Windows 11 には組み込まれており、Windows 10 ではストア アプリが起動時にこれを検出して、インストールがブロックされない限りインストールします。
• 支援側には Microsoft または Entra アカウントが必要です。ローカル アカウントのみで作業している技術者はアクセス手段がありません。
• 権限昇格はセキュア デスクトップ上で行われます。そこで UAC の資格情報プロンプトが表示されると、支援側からはそのプロンプトが見えなくなり、入力もできず、セッションが行き詰まります。ある Microsoft Q&A の投稿者は次のシナリオを説明しています: 既定でユーザーはすべて標準ユーザー、管理者プロンプトでは画面が真っ黒になり、リモートでインストールを完了する方法がない。
• 一般的な macOS のサポートはありません。macOS ビルドは存在しますが、Microsoft はそれを Microsoft Support とのやり取りに限定しており、自分たちのセッションでは利用できません。
確認済みの解決策 3: Windows リモート アシスタンスと、私がそれに頼るのをやめた理由
Windows リモート アシスタンス は依然として msra.exe として提供されており、Microsoft の Windows クライアント向け非推奨機能一覧には掲載されていません。ただし、一覧にないことは、そのワークフローを無期限にサポートすることを約束するものではありません。最近のビルドでは、支援を申し出る経路は十分に信頼性が低く、主要なツールとしては除外せざるを得ません。
管理者は Windows 10 22H2 および Windows 11 24H2 で Your offer to help could not be sent のエラーが発生し、あわせて Microsoft-Windows-DistributedCOM: DCOM got error "2147746132" when attempting to activate the server {833E4010-AFF7-4AC3-AAC2-9F24C1457BCE} の Event ID 10006 が記録されると報告しています。Microsoft Q&A に投稿したエンジニアは、すでに Remote Assistance のファイアウォール規則が有効、DCOM が有効、GPO 経由で起動とアクティブ化のアクセス許可を適用、ポート 135 が応答、KB5030211 をインストール済み、同じ 2 つのホスト間で通常の RDP が動作、と確認していました。同一構成でも一部のデバイスでは失敗し、別のデバイスでは動作しました。この質問には受理された回答は付きませんでした。
Windows フォーラムで出回っている一部の対処法は、DCOM の権限を編集することです。dcomcnfg を実行し、Component Services, Computers, My Computer, DCOM Config を展開し、上記の CLSID を見つけて Properties、Security を開き、Launch and Activation のアクセス許可を編集して、アカウントに Local Launch と Local Activation を付与します。24H2 では結果が一貫しません。
もう一つ出回っている回避策は、HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DCOM 配下の EnableAuthEpResolution を 0 に設定するというものです。これは避け、添えられている理屈にも注意してください。フォーラムの投稿ではこのキーを CVE-2021-26414 による DCOM の強化と結び付けるのが常ですが、その割り当ては誤りです。CVE-2021-26414 の強化に対する Microsoft のスイッチは HKLM\SOFTWARE\Microsoft\Ole\AppCompat 配下の RequireIntegrityActivationAuthenticationLevel で、KB5004442 に文書化されており、2023 年 3 月 14 日に任意設定ではなくなりました。EnableAuthEpResolution は別物で、はるかに古い RPC の設定であり、クライアントがエンドポイント マッパーに対して認証するかどうかを制御します。これを無効にすると、Microsoft がすでに置き換えた画面共有ツールを復活させるために、マシン全体の RPC 認証が弱体化します。
ソフトウェアのインストール不要の無料リモートデスクトップ: 各オプションにかかるコスト
どの選択肢にも何らかの負担が伴い、役に立つ問いは、そのコストのどれがあなたが助けている相手にのしかかるのかという点です。無料のインストール不要のリモートデスクトップというカテゴリーは実在し、さらに区別して語る価値のある2つの系統に分かれます。
| オプション | クライアント側の操作 | かかるもの |
RDPmstsc.exe 経由 |
なし | ユーザーのセッションはロック画面に切り替わる |
| RDP シャドウイング | なし | Pro エディション、ローカル管理者権限、RPC 到達性、LAN または VPN |
| クイック アシスト | コードを入力し、許可 | ストアから未インストールの場合はインストールが必要、支援者には MSA が必要、セキュア デスクトップの UAC によりリモートでの表示や操作がブロックされる場合がある |
| Windows リモート アシスタンス | 招待を開く | DCOM のアクティブ化が失敗するのは 22H2 と 24H2 |
| Microsoft Intune Remote Help | アプリをインストールしてサインイン、または共有者向け Web アプリで閲覧のみを共有 | 支援者と共有者の両方にライセンスが必要、両者が同一の Entra テナントである必要があり、完全な制御と昇格にはネイティブ アプリが必要 |
| ブラウザーのみのツール | リンクを開く | 実際には制御が制限されることが多く、どこが制限されるかはマーケティングではほとんど示されない |
| 実行専用のサポート アプリ | ダウンロードしたファイルを実行し、同意ボタンをクリック | バイナリが ダウンロード に配置され、インストーラーなし、昇格なし |
保持しておくべき区別は、何がシステムに影響を与えるかという点です。インストーラーは Program Files に書き込み、サービスを登録し、管理者パスワードを必要とします。ポータブル バイナリはユーザー自身のトークンの下で Downloads フォルダーから実行され、セッションが終了すれば関係がなくなります。
単なる Quick Assist 以上を必要とするチームに対する Microsoft 独自の解としては Intune Remote Help があり、これは 1ユーザーあたり月額 3.50 USD のスタンドアロン アドオンとして、または Intune Suite を通じて提供されています。Microsoft は 2026年7月に高度な Intune 機能を Microsoft 365 E3 および E5 に統合し始めたため、席を購入する前にテナントに既に含まれている内容を確認し、対象ライセンスがあってもそれだけでサービスが自動的に有効になるわけではない点に注意してください。
Microsoft の計画ドキュメントはシートに関する疑問を解消しています。つまり、Remote Help のライセンスは、Intune Plan 1 または Plan 2 に加えて、サービスの利用対象となる全員(支援者と共有者の双方)に割り当てます。また、Quick Assist のページでは、監査証跡と条件付きアクセス制御のため、単一テナント組織を Remote Help に誘導するようになっています。
外部のクライアントを支援する場合に重要な境界がひとつあります。Remote Help は組織内サポート向けに構築されており、支援者と共有者は同じ Microsoft Entra テナントに属している必要があるため、テナント間のセッションはサポートされません。共有者がネイティブ アプリをインストールできない場合、Microsoft は Web アプリを提供しており、支援者には操作ではなく閲覧のみのアクセスが与えられます。
HelpWire: 最小限のクライアント側セットアップでリモートサポートセッションを開始
HelpWire はリンクから立ち会いセッションを開始でき、クライアント側のセットアップはダウンロードしてダブルクリックし、同意ボタンを1回押すだけで、インストーラー不要・管理者権限不要・アカウント作成不要です。以下のフローはQuick Connectの手順で、あなた側でもアカウントは不要です。
-
HelpWire Quick Connect をダウンロードして、お使いのコンピューターで起動してください。
-
アプリから接続リンクをコピーし、メール、メッセージングアプリ、テキストメッセージ、またはヘルプデスクのチケットを通じて送信してください。
-
クライアントはリンクを開きます。利用中のオペレーティングシステムが検出され、ダウンロードが開始されます。クライアントアプリは既定でポータブルなので、ダウンロードしたファイルをダブルクリックして実行します。
-
アプリが起動すると、アクセスリクエストは自動的に相手に届きます。クライアントがアプリを起動したら、内蔵のチャットで連絡を取ることもできます。
-
クライアントはアクセスを許可をクリックします。
-
HelpWire のインターフェースからワークステーションを操作します。クライアントはいつでも許可を取り消すをクリックでき、あなたのアクセスは直ちに終了します。
-
完了するには Disconnect をクリックしてください。クライアントのリンクは期限切れになり、クライアント側のアプリは非アクティブになります。新しいセッションには新しいリンクが必要です。
Quick Connect は1回限りのセッションを対象とします。無人アクセスをリクエストすれば、クライアントが不在でも後で再接続できます。
実際の現場でのインストール不要のリモートサポート向けの RDP と HelpWire の比較
最適なツールは、あなたがそのマシンを管理しているかどうかに左右されます。また、その分かれ目は、機能リストが示唆するよりもずっと明確です。
| シナリオ | RDP とシャドウイング | HelpWire |
| 親戚が Windows 11 Home、別の都市 | RDP をまったくホストできないため、シャドウイングは利用できません。 | リンクとポータブル クライアント アプリ、エディション要件なし |
| 標準ユーザーはドライバーのインストールが必要 | シャドウイング(/control)では、UAC プロンプトがセッション内に表示されて資格情報を入力できますが、完全なシャドウイングのセットアップを終え、到達可能なネットワーク上にある場合に限ります。 クイック アシスト はプロンプトで表示が失われることがあります。 |
管理者アクセスを要求し、クライアントが UAC を承認、セッションは昇格状態で再開 |
| 同一 LAN 上のドメイン ワークステーション | GPO、RPC、ファイアウォール ルールを準備すれば良好に動作します。 | エンドポイント側で何も事前準備せずに動作します |
| 別の国で CGNAT 配下にあるクライアント | VPN か公開された 3389 が必要で、どちらもあなたが運用責任を負うことになります。 |
ポートフォワーディング不要のリンクベースのセッション |
| 見知らぬ人の PC での単発セッション | 同意プロンプトなし、チャットなし、クリーンな終了状態なし。 | 同意プロンプトあり、チャットあり、切断時にリンクは失効 |
よくある質問
RdpSa.exe プロセスを探し、ターミナル サービスの接続ログを確認します。RdpSa.exe はシャドウ セッションがアクティブな間にのみ実行されるため、タスク マネージャーに存在していれば稼働中であることの指標になります。履歴を確認するには、Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational を開きます。セッション ログでは、許可の付与は 20508、開始は 20503、停止は 20504 を参照します。/control で開かれたセッションは代わりに 20506 と 20507 に記録されるため、両方のセットを照会しないと、本記事が設定するまさにこの種類のセッションを見落とします。
Get-WinEvent -FilterHashTable @{LogName='Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational';ID=20503,20504,20506,20507,20508}
一般的な原因は、Quick Assist のインストールの破損、VPN やプロキシの干渉、Microsoft サービスのエンドポイントのブロックです。次の順に対処してください。設定、アプリ、インストールされているアプリ、Quick Assist、詳細オプション を開き、修復をリセットより先に使用します。Microsoft Q&A で関連する Session ended エラーは VPN 接続に起因すると繰り返し追跡されているため、VPN クライアントを切断してください。次に、スタート メニューから管理者として Quick Assist を起動してみてください。まだ Connecting のまま固まる場合は、マシン側ではなく、プロキシまたはコンテンツ フィルターがエンドポイントをブロックしています。
エンドポイントをブロックし、その後アプリを削除します。Microsoft が文書化している方法は、クイック アシスト がセッションを確立するために使用する主要なエンドポイントである remoteassistance.support.services.microsoft.com へのトラフィックをブロックすることです。これをブロックすると、アプリはサポートを受けることも他者をサポートすることもできなくなります。このエンドポイントをブロックすると Intune Remote Help も中断されると Microsoft は警告しているため、広範にブロックを適用する前に影響を検証してください。アプリ自体を削除するには、管理者として次を実行します:
Get-AppxPackage -Name MicrosoftCorporationII.QuickAssist | Remove-AppxPackage -AllUsers
設定、アプリ、インストールされているアプリ、クイック アシスト と進み、その後省略記号を選択して アンインストール することでもアンインストールできます。組織が別のサポート ツールを標準としている場合は、完全に削除することを Microsoft は推奨しています。残したままにすると、外部者に貴社のエンドポイントへの有効な経路を与えることになるためです。
はい、リモートの両方のモニターは常にお使いのローカルコンピューターの1台のモニター上に表示されます。これはバグではなく設計によるものなので、シャドウ表示がご自身の2台目のモニターにまたがることはありません。/span と /multimon スイッチは標準の RDP セッションに適用され、シャドウ接続には影響しません。
デスクトップの Windows マシンでは Alt とアスタリスクキーを、RDS セッションホストでは Ctrl とアスタリスクキーを押します。Ctrl + Alt + Break はシャドウウィンドウを画面いっぱいに収まるようにサイズ変更し、これは初回のセッション前に覚えておく価値のあるもう一つのショートカットです。
文書化された方法はありません。Microsoft は IT ドキュメントにおいて Quick Assist の対象を Windows 10 と Windows 11 に限定しており、Windows Server エディションは記載されていません。また、Windows Server 2008 R2 では利用不可であると明記されています。サーバー セッションの場合は、ホスト上の管理セッションからサーバー セッションをシャドウするか、サーバー対応が文書化されているサポート ツールを使用してください。リモート デスクトップ セッション ホスト を運用しているチームは、この理由だけで結局シャドウイングに頼ることになります。
プロのコツ: no-install パスは呼び出しの最中ではなく、呼び出す前に準備してください
今日、マシンを2つのグループに分け、それぞれを個別に準備してください。あなたが管理するエンドポイントでは、今すぐGPO経由でShadow、AllowRemoteRPC、およびシャドウ用のファイアウォールルール2つを展開し、ライブセッションに必要なのはセッションIDと同意のクリックだけにしておきましょう。あなたの管理外のものについては、リンクベースのセッションを用意しておき、必要になる前に実際の標準ユーザーアカウントで権限昇格の経路を一度テストしてください。通話の最中にツールがUACプロンプトを超えられないことが判明すると、そのコストはセットアップ全体にかかる費用よりも高くつきます。