あなたがリモート再起動をクリックし、マシンはダウンしたものの、二度と復帰しませんでした。あるいは再接続のプロンプトが表示され、クリックしたのに、結局セッションは切断されました。あるいは、リスト上ではデバイスはオンラインのまま表示されているのに、接続を試みるたびに失敗します。再起動はリモートアクセスに必要な要件を壊してしまい、これがほぼすべての失敗を説明します。たとえば、ローカルで誰かがログインするまでリモート側で何も応答しなかったり、再起動前に使えていた認証情報が再起動後には存在しなくなっていたりします。以下で、どれに該当するのかと、効果が持続する対処法をお伝えします。
再接続の手順自体が毎回失敗する場合は、HelpWire は別の方法で対処します。IT チームや技術者向けのリモートアクセスソフトウェアで、リモートシステムが再起動するか、ユーザーがログアウトした後に、自動的にセッションに再接続します。これはここでの状況にまさに当てはまります: 途中で再起動が必要なアップデートやドライバー作業。
TeamViewer の再起動と再接続: ボタンの機能
TeamViewer の再起動と再接続は、二段階のハンドシェイクです。セッション内から再起動をトリガーすると、TeamViewer はパートナーを待つかどうかを確認し、そのエンドポイント用のマーカーを保持し、リモートデバイスがオンラインに復帰したことを報告すると Reconnect ボタンを提示します。
その一度のハンドシェイクの範囲内では、再接続時にパスワードを再度求められることはありません。ただし、その後に使える認証情報が残ることはありません。また、ID が変更されると有効ではなくなり、Reconnect ボタンを渡す際にリモート側のソフトウェアが準備できているかを検証もしません。
TeamViewerは再起動後に再接続しますか: 3つの条件
再起動後に TeamViewer は再接続しますか には明確な答えがあります: 条件が同時に3つ満たされれば「はい」いずれかが欠ければ「いいえ」です。リモート側は、一度だけ実行されるモジュールではなく、サービスまたはデーモンとして常駐するインストール済みクライアントを実行している必要があります。あなたは、そのセッションのマーカーまたは再起動後も有効な資格情報を保持している必要があり、かつ双方がサポート対象のプラットフォームの組み合わせでなければなりません。Windows では、その常駐コンポーネントは TeamViewer サービスであり、このため下記の Fix 3 ではそのスタートアップの種類を確認します。
TeamViewer のスタッフは、接続維持に関するコミュニティスレッドでプラットフォームに関する規則を直接述べています:再起動しての再接続は、Windows から Windows または Mac、および Mac から Windows または Mac で機能します。Linux はその組み合わせの対象外です。TeamViewer 自身のナレッジベースは二つ目の制限を追加しています:再起動機能は macOS ではまだサポートされておらず、現在も開発中です。したがって、その組み合わせで Mac はコントローラーにはなれますが、ボタン自体の対象にはなれません。
再起動後のTeamViewer再接続: 確実に効く対処法
これらは順番に実行してください。修正1と2だけで、再起動後にTeamViewerが再接続しない事例の大半が解決します。また、以下の各修正はすべて、ベンダーのドキュメント、サポートコミュニティ、または公開フォーラムの技術者によって確認されています。
対処法 1: リモート側を QuickSupport から切り替える
何かを再起動する前に、QuickSupport を TeamViewer Hostに置き換えてください。TeamViewer は個人用パスワードに関するドキュメントでこの制約を明確に述べています:無人アクセスは Host またはフルバージョンでのみ動作し、QuickSupport は対応していません。Host は Windows サービスとしてインストールされます。したがって、ユーザーが存在しなくてもログオン画面で応答し、TeamViewer はセッション中のアップグレード手順を文書化しており、2 回目のダウンロードリンクも電話も不要です。
アクティブな QuickSupport セッションで、リモートセッションのツールバーにある Files & Extras を開きます。
TeamViewer をリモートでインストール にカーソルを合わせ、 TeamViewer Host をインストール を選択します。
ホストモジュールをインストールで確認します。TeamViewer から、いったん終了して新しいバージョンをインストールする旨の警告が表示されます。OKをクリックするか、カウントダウンが終了するまで待ちます。
Host のインストール後に自動的に再接続するかどうかを尋ねられたら、パートナーを待つをクリックします。
インストールが完了したら、Reconnect をクリックします。TeamViewer の Host-via-QuickSupport article によると、この再接続には新しいパスワードは必要ありません。
リモートデバイスで TeamViewer Host を開き、Manage this device をクリックして、TeamViewer の認証情報でサインインします。これによりデバイスがあなたのアカウントに割り当てられます。現行のドキュメントでも手順はここで終了しており、これが次回の再起動を乗り切れるようにする鍵です。
この手順には1つの制約があります。TeamViewer は、セッション中の Host のインストールは Windows デバイス間の接続でのみ機能すると述べています。Mac や Linux マシンから操作している場合はこの方法は使えず、代わりにリモート側のユーザーが手動で Host をインストールします。
ドライバーが動作する前にこれを行ってください。いったんマシンがダウンすると、手順1を実行するためのセッションがありません。
対処法 2: 個人用パスワードを設定するか、簡単アクセスを許可する
個人用パスワードは生成されるのではなく保存されているため、再起動しても保持されます。セッションを保持しているうちに、リモートマシン上で設定してください。TeamViewer はこの設定をセキュリティから詳細オプションへ移動したため、現在の文書化された手順は歯車アイコン経由になります。
リモートデバイスで TeamViewer (Classic) を開き、右上隅の 歯車アイコン をクリックします。
詳細 を選択し、詳細オプションを表示 で確認します。
このコンピューターへの接続の詳細設定 と 個人用パスワード セクションまでスクロールしてください.
パスワードを両方のフィールドに入力し、OKをクリックしてください。TeamViewerは辞書にある単語やキーボード上の連続した並びを拒否し、少なくとも8文字を要求します。
長期的に管理するデバイスについては、代わりにそのデバイスを割り当ててください。リモート側のマシンで、歯車アイコンの 設定 を開き、全般 タブで このデバイスを管理 までスクロールしてクリックし、TeamViewer の認証情報でサインインします。次に その他、オプション、セキュリティ を開き、簡単アクセスを許可 を 無人アクセス の下で有効にします。簡単アクセスはパスワードを手順から完全に取り除くため、リモート側のバージョン更新によって作業中にパスワードが変更されるケースもなくなります。
対処法 3: ログオン前に TeamViewer サービスの開始を強制する
サービスを 自動 に設定し、実行されていることを確認してください。というのも、手動 起動では、ローカルにログインするまで何も応答しないためです。これは、再起動に関するスレッドで TeamViewer サポートが最初に確認を求める項目で、Windows と同時に TeamViewer を起動 オプションと並んでいます。
リモート コンピューターで、Win + R を押し、
services.mscと入力して、Enter を押します。TeamViewerという名前のエントリを見つけてください。バージョンの接尾辞は TeamViewer 11 以降、サービス名から削除されているため、現在のビルドではTeamViewer15ではなくTeamViewerとして登録されます。それを右クリックして、プロパティを選択します。
スタートアップの種類 を 自動 に設定します。
サービスの状態 が 実行中 であることを確認し、適用 と OK をクリックします。
TeamViewer で、その他、オプション、全般 を開き、Windows の起動時に TeamViewer を起動 にチェックが入っていることを確認します。
確認するには、コマンドラインから、Services コンソールではなく、リモート マシン上の管理者権限の PowerShell ウィンドウで次を実行します:
Get-Service -Name TeamViewer | Select-Object Name, Status, StartType
もし StartType が Manual を返す場合は、次で修正します:
Set-Service -Name TeamViewer -StartupType Automatic
対処法 4: 更新後に Windows が自動的にサインインし直すようにする
自動再起動サインオン を有効にすると、更新プログラム適用後の再起動で、Windows は最後に対話的に使用していたユーザーで再サインインし、セッションをロックします。Windows Update は、サインイン中のユーザーの派生資格情報を抽出してディスクに保存し、自動ログオン を構成したうえで、次回の起動時にサインインしてデバイスをロックします。リモート アクセスにとって重要なのは、ユーザー セッションが再び存在することで、サインイン済みのデスクトップに依存するものはすべて動作する点です。
リモート コンピューターで、設定、アカウント、サインイン オプション の順に開きます。
Windows 11 では、追加設定までスクロールし、更新後のセットアップを自動的に完了するためにサインイン情報を使用するをオンにします。Windows 10 では、同じトグルはプライバシーの下にあり、更新または再起動後にデバイスのセットアップを自動的に完了するためにサインイン情報を使用すると表示されます。
トグルがグレーアウトしている場合、一般的な理由は2つあります。アカウントで Windows Hello の資格情報が構成されていないか、デバイスがドメインに参加しており、そのオプションが組織のポリシーによって制御されていることです。以下のポリシーに関する手順は2番目のケースを対象としています。
Windows の Pro および Enterprise では、代わりにポリシーで設定してください:
Win + R を押し、
gpedit.mscと入力して、Enter を押します。コンピューターの構成、管理用テンプレート、Windows コンポーネント、Windows ログオン オプション に移動します。
再起動後に最後の対話型ユーザーに自動的にサインインしてロックするを開き、有効に設定します。
これが役立つかどうかは 2 つの制限によって決まります。Microsoft は管理対象デバイスと非管理対象デバイスを区別しています。非管理対象デバイスではデバイス暗号化を使用しますが必須ではありません。一方、管理対象デバイスでは TPM 2.0、 SecureBoot、および BitLocker、ARSO がそもそも構成される前に必要です。管理者はポリシーによってその要件を上書きできます。管理対象デバイス上の ARSO は現在、Microsoft Entra IDに参加しているデバイスでのみ利用可能です。
2 つ目の制限はサポート作業の際により重要です。管理対象デバイスでは、自分で開始した再起動では ARSO は適用されませんが、Windows Update の再起動では適用され、次のコマンドでも同様ですshutdown -g -t 0。このコマンドは、自分で開始した再起動の後に Windows にユーザーを再サインインさせたい場合に使用します。 この機能を制御するレジストリ値 DisableAutomaticRestartSignOn は HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System にあり、0 で有効になります。
対処法5: ネットワーク アダプターと高速スタートアップを原因から除外する
ネットワーク アダプターの電源管理は、問題の兆候もなくマシンをネットワークから切断してしまうことがあり、どの起動にも当てはまります。 高速 スタートアップ は再起動にはまったく適用されないため、リモート再起動 の経路については何も説明しません。しかし、クライアントに対して一般的に勧められるフォールバックの助言は、マシンをシャットダウンして電源を入れ直すことなので、同じ段階で扱うべきです。これはまさに 高速スタートアップ が対象とする経路です。
リモート マシンでデバイス マネージャーを開き、ネットワーク アダプターを展開し、アクティブなアダプターを右クリックして、プロパティを選択します。
電源の管理 タブを開き、電力の節約のために、コンピューターでこのデバイスの電源をオフにできるようにする の選択を解除します。
OKをクリックします。
コントロール パネル、電源オプション、電源ボタンの動作の選択を開きます。
現在利用できない設定の変更をクリックします。
高速スタートアップを有効にする(推奨)のチェックを外して、変更を保存します。
どの修正がどの構成に適用されるか
| リモート側のセットアップ | 再起動後に見える状態 | ここから開始 |
|---|---|---|
| QuickSupport(Windows 版) | エンドポイントが消えている。再接続が行われない。 | 対処 1 |
| フルクライアント、ランダムパスワードのみ | デバイスはオンライン、パスワードは拒否される。 | 対処 2 |
| ホストまたはフルクライアント、サービスが 手動 に設定 | ローカルにログインするまで応答がない。 | 対処 3 |
| 機能更新後のドメイン参加済み Windows 11 | ログオン画面には到達するが、ユーザーセッションがない。 | 対処 4 |
| ノートPCまたはミニPC、ふたが閉じている | 誰かが操作するまで接続できない。 | 対処 5 |
| Linux エンドポイント(Ubuntu、Debian、Fedora) | リモート再起動 がグレーアウトし、再接続の案内がない。 | サポートされていません。OS 内から再起動して手動で再接続してください。 |
なぜアップデートやドライバーのインストール後に、再起動後の TeamViewer の自動再接続が失敗するのか
再起動後の TeamViewer の自動再接続 は、更新やドライバー関連の作業中に最も頻繁に失敗します。というのも、その作業が再接続の前提となる要素を変更してしまうからです。Windows の更新による再起動は、誰もサインインしていないログオン画面の状態でマシンを戻してしまいます。ドライバーのインストールによって、再接続をキューに入れていたものとは異なる TeamViewer ID になってしまうこともあります。いずれもネットワークエラーとしては表面化しないため、標準的なチェックリストでは何も見つかりません。
報告の原因は4つの障害モードに集約でき、それらはすべて TeamViewer のサポートコミュニティまたはナレッジベースに記載されています。
TeamViewer が再起動するたびにアクセスパスワードが再生成されます
ランダムアクセス用のパスワードは、TeamViewer のプロセスの存続期間に紐づいています。再起動すると TeamViewer も再起動され、新しいパスワードが生成されます。 Keep current オプションは、エンドユーザーが TeamViewer を再起動しない限りパスワードを保持しますが、ランダムパスワードの変更を防ぐ方法はありません。
次の項目には 4 つの値が存在します Random password after each session。これは TeamViewer の ランダムパスワードのドキュメントに記載されています: Keep current、 Generate new、 Deactivate、および Show confirmation。これらは TeamViewer の再起動後に何が起こるかではなく、セッション終了後に何が起こるかを制御します。また、Keep current は、アプリケーションが再起動されるまでしか保持されないと TeamViewer が明示しています。個人用パスワードまたは Easy access だけが、この 4 つのいずれが設定されているかに依存しない方法です。
誰かがローカルでログインするまで、何も応答しません
リモート側が QuickSupport を実行している場合、再起動するとエンドポイントが削除されます。QuickSupport はサービスも自動起動エントリもない一回限り実行の実行ファイルであり、TeamViewer は その制限をドキュメントで明記しています。無人アクセスが機能するのは Host かフルバージョンのみで、QuickSupport はそれをサポートしません。フルクライアントを使用し、クライアント側で QuickSupport を使っている登録ユーザーが 結果を説明しました、その結果は、リモート再起動後に自動で再接続できず、毎回リモート側のユーザーが手動で接続を承認しなければならないというものでした。
同じ症状はフルクライアントでも、Start TeamViewer with Windows がオフのとき、または TeamViewer_Service.exe が Startup type Manual の場合にも現れます。 Windows 10 ビルド 15063.138 に関して立てられた TeamViewer コミュニティのスレッドは、そのパターンを正確に記録しています。アップグレード後、そのマシンはコンピューター一覧から消え、投稿者がローカルにログオンした瞬間に再び現れ、次の再起動でまた消えました。確認するたびにサービスは自動に設定され実行中でした。まずサービスの開始種類を確認し、次に teamviewer.exe がログイン後に実行されているかを確認し、最後に PC がオンラインかどうかを確認してください。
ドライバーの再インストールにより、TeamViewer ID が変更されることがあります
ネットワークアダプタードライバーを再インストールすると、再起動後に別の TeamViewer ID になる場合があります。TeamViewer コミュニティのあるユーザーが 一連の流れを説明しています:誤ったネットワークアダプタードライバー、アンインストール、正しいドライバーでの再インストール、再起動、そして新しい ID。彼のログには理由が示されており、その理由は MID が変更されたことでした。TeamViewer は MID に何が関与しているのかを公開しておらず、そのスレッドも回答が得られなかったため、これは文書化された規則というよりも既知の結果として受け止めてください。
これは、ドライバー作業の前に誰も警告してくれない障害モードです。再接続マーカーは古い ID を指しています。マシンはオンラインで到達可能で、あなたがもはや持っていないアドレスに応答します。Windows の機能更新でも同様の結果が生じており、Windows 10 May 2020 Update 後に報告されています。
リモートモジュールの準備が完了する前に再接続プロンプトが表示されます
その 再接続 ボタンはリモート側のソフトウェアが起動する前にクリック可能になり、早まってクリックするとセッションが破棄されます。技術者が、コミュニティのスレッドで、QuickSupport の再起動に関してその手順を記録しています: すべてのプロンプトは正しく表示されたものの、再接続は一度も確立されず、彼自身のテストでは、Windows が起動してからしばらく経つまで QuickSupport は開始されない一方で、再接続ボックスは直ちに表示されることが示されました。モジュールが動作を開始する前にクリックすると、セッション全体が失敗し、クライアントが新しいセッションを開始する以外に復旧手段はありません。
モジュールの状態を示すインジケーターはなく、あなたの側からそれをポーリングする方法もありません。ボタンが示しているのは、その背後にあるソフトウェアの準備完了ではなく、デバイスが応答したということです。
ほとんどの人が最初に試すこと、そしてそれがうまくいかない理由
この問題に関するほぼすべてのスレッドで4つの対処法が挙がりますが、どれも根本原因のいずれにも対処していません。
TeamViewer を再インストール。これは次回の起動まで接続を復旧しますが、その後同じ症状が再発します。 フォーラムスレッド は NOT READY: Please check your connection エラーについてまさにそのループをたどりました。再インストールは有効でしたが、次回の再起動でまた壊れました。
TeamViewer サービスを再起動。マシンに到達できるときにはもっともな助言です。問題の本質は、それができないことにあります。
ポートを開放し、3389 を転送。これは RDP のガイドに由来しますが、受信ルールを必要としない TeamViewer には何の効果もありません。ポート 3389 は Remote Desktop Protocol に属するもので、失敗の特性が異なる別の製品です。
Wake-on-LAN。マシンはすでに電源が入っており、ping に応答します。電源状態には何の問題もありません。
さらに2つ、修正に見えるものがありますが、違います。 サインインしたままにする は一般的な解決策として勧められますが、リスナーにもアクセス用パスワードにも関与しないため、解決策ではありません。まさにこの質問に関する コミュニティスレッド で、あるユーザーはそれを有効にしていても再起動後に接続できなかったと回答しています。これが重要になるのはただ1つの場合だけです。下の表にある商用利用ブロックの場合です。
2つ目はより微妙です。 Windows と同時に TeamViewer を起動 は正しい設定です。これは TeamViewer を Windows のシステムサービスとしてインストールし、Windows のログイン前に応答できるようにするためです。しかし、そのチェックボックスにチェックが入っていても、サービスが依然としてそのように設定されている証拠にはなりません。ユーザーからは、このオプションがバージョン更新後にデフォルトに リセットされる と報告されているため、チェックボックスではなく services.msc でサービスを確認してください。また、上で述べた理由により、再起動後はデバイス一覧のオンラインインジケーターを信用できません。
エラーメッセージとそれぞれの意味
何かを変更する前に、表示されている文字列を原因と照合してください。
| メッセージ | 示す内容 | まず行うこと |
|---|---|---|
Partner did not connect to router. Error Code WaitForConnectFailed | いずれか一方のデバイスでの接続性の問題。診断ではなく症状であり、再起動後によくある原因はリモート側が復帰していないことです。 | まず接続性を確認し、その後 Fix 1 と Fix 3 を実施してください。 |
Not ready. Please check your connection | リモートクライアントが TeamViewer のサーバーに到達できません。TeamViewer が示唆する一般的な原因は、インターネット接続の問題、外部への経路がないクライアント、送信ポート 5938 のブロック、または TeamViewer のサービス/ステータスの問題です。 | そのマシンがオンラインであることを確認し、その後 Fix 3 を実施してください。 |
Commercial use suspected 再起動後 | TeamViewer の商用利用検出であり、再起動の不具合ではなくライセンスの問題です。再起動後に現れるのは、そのタイミングで次の接続を試みるためです。 あるライセンス保有ユーザーが報告しています が、まさにその順序で発生しました。 | ライセンスは接続元のマシンに紐づくため、接続 from のマシンでサインインしていることを確認し、そのうえでライセンスの問題として対処してください。 |
黄色の Connecting... がいつまでも解消しない | エンドポイントは登録されていますが、セッションがディスプレイにアタッチできません。以前のセッション終了後に Linux エンドポイントでよく発生します。 | ローカルで再起動してください。再接続機能では対処できません。 |
Remote Desktop can’t connect to the remote computer for one of these reasons: | TeamViewer ではなく RDP の問題です。よくある一般的な失敗で、既知の原因としては、リモート デスクトップが有効化されていない、マシンがオフライン、ネットワークの問題、あるいはリスナーとそのサービスが動作していない、などがあります。 | 下記の RDP セクション。 |
Error code: 0x10b Extended error code: 0x0 | リモート コンピューターへの接続が失われたことを示す一般的な RDP メッセージです。診断ではなく症状であり、あらゆる種類の切断セッションで現れます。 | 起動ごとに一度しか接続できないバリアントに関する Microsoft Q&A スレッド は症状を記録していますが、確定した修正は提示されていません。 |
誰も制限しないプラットフォーム、ドキュメントを一か所に
再起動と再接続は、機能一覧が示すほど広くはなく、制限は3つの別々の文書に記載されています。この表はそれらをまとめています。
| リモート接続先 | リモート再起動の可否 | セーフモードで再起動 | 自動再接続 |
|---|---|---|---|
| Windows | はい | はい | はい、Windows または Mac のコントローラーから |
| macOS | いいえ。TeamViewer のドキュメントでは、まだサポートされておらず、開発中とされています。 | いいえ | Windows または Mac のコントローラーからサポートされていますが、再起動は macOS 内から開始する必要があります |
| Linux | いいえ。 Actions の項目はグレーアウトされています。 | いいえ | いいえ |
15.6.7 を使う Ubuntu 18 の 2 台のマシンで Remote Reboot オプションがグレーアウトしていると報告は Actions メニューで、再起動のたびにリモートマシンへ物理的にアクセスしなければならないとも述べました。スレッドでは解決策は得られませんでした。再起動後、プレーン RDP でリモート デスクトップに接続できない場合はどうすればよいですか?
TeamViewer ではなく Windows リモート デスクトップを使用していて、 再起動後にリモート デスクトップに接続できない場合は、ネットワークではなくサービスから確認を始めてください。 リモート デスクトップ サービス、という名前のサービスである TermServiceは、既定で 手動 のスタートアップの種類となっており、オンデマンドで起動する想定ですが、更新後の再起動ではまったく起動してこないという不具合に遭遇することがあります。
TermService が実行中であることを確認し、その後、そのスタートアップの種類を変更します
Win + R を押し、
services.mscと入力して、Enter を押します。一覧から リモート デスクトップ サービス を見つけます。
それを右クリックし、プロパティを選択し、スタートアップの種類を自動に設定します。
サービスが停止している場合は、開始 をクリックし、次に 適用 と OK をクリックします。
管理者権限の PowerShell セッションから:
Set-Service -Name TermService -StartupType Automatic
Start-Service -Name TermService
2つ目のサービスと、リスナーが実行されていることを確認する方法
Microsoft はこのエラーで確認すべきサービスを 2 つだけ挙げています: リモート デスクトップ サービス (TermService) と リモート デスクトップ サービス ユーザーモード ポート リダイレクター (UmRdpService) で、両方が実行中であることを確認するよう述べています。起動の種類は指定していません。
この 自動 への変更は現場からの知見です。 Microsoft の Q&A フォーラム で、ある慈善団体の IT 管理者が、更新の再起動のたびに RDP を拒否し、接続を受け付けるには 2 回目の再起動が必要なデスクトップについて説明しました。彼は TermService と UmRdpService を 手動 から 自動 に変更しました。これは以前の 3 台のクライアントでも同様のランダムな障害を解消しており、このマシンではさらに 高速スタートアップ が有効のままだったため、 HiberbootEnabled = 0 で無効化しました。どちらの確認も同じ手順の中で行うべきです。
それらを変更する前に、まずリスナーが動作しているかを確認してください。リモート側のマシンで管理者特権のコマンド プロンプトから qwinsta を実行します。出力には rdp-tcp の行が Listen 状態で表示されるはずです。その行がなければ、リスナーは停止しており、ネットワーク側の対処では解決しません。
リスナーが動作しているのに接続が失敗する場合は、マシンがセットアップの途中で止まっていないか確認してください。 このエラーに関する Microsoft のガイド は、次の場所にある 2 つのレジストリ値を示しています HKLM\SYSTEM\Setup: SystemSetupInProgress と OOBEInProgress。どちらも 0 である必要があります。
HelpWire による再起動と再接続の処理方法
HelpWire は、リモートシステムの再起動後やユーザーのログアウト後にセッションに自動的に再接続し、これは TeamViewer では上記の5つの対策が保護するために存在するワークフローの一部です。
仕組み
リモートマシン上の HelpWire クライアントアプリが無人アクセスの許可を保持しているため、アクセスは起動時にローテーションするパスワードに依存しません。HelpWire の Web ポータルのワークステーション タブまたはオペレーター アプリで、リクエスト 無人アクセスをクリックするだけで、リモートユーザーが許可を与えます。
特にアップデートやドライバー作業の場合、3 つの点が変わります。パスワードは起動時にローテーションされないため、マシンが戻った後に再入力する必要はありません。オペレーター ツールバーの管理者アクセスをリクエストでセッション内で管理者権限への昇格が可能なので、UAC で制御されるインストーラーでも誰かがキーボードの前にいる必要はありません。また、組織に所属している場合、その許可は組織に帰属するため、最初の技術者がシフトを終えたときにチームメイトが同じデバイスを引き継ぐことができます。
注記: FileVault を有効にした macOS では、無人セッションを開始できるようになる前に、毎回の再起動後にリモートユーザーが自分のアカウントにログインする必要があります。これは HelpWire の制限ではなく macOS の制限です。Linux では、再起動に関する重要な点として、HelpWire は Wayland と X11 のセッションをサポートしていますが、OS の制限により Wayland ではログイン画面に到達できません。つまり、再起動した Wayland デスクトップには、誰かがサインインした後にのみ再びアクセス可能になります。
比較: 3つのツールにおける再起動と再接続
| 機能 | TeamViewer (Host またはフルクライアント) | Windows RDP | HelpWire |
|---|---|---|---|
| リモート再起動後に再接続 | はい、Windows と Mac のペアのみ | プロンプトはありません。手動で再接続します。 | はい、再起動またはログアウト後 |
| 再起動後も資格情報が保持される | 個人用パスワードまたは Easy access のみ | Windows アカウントの資格情報 | 無人アクセスの付与、パスワードのローテーションなし |
| セーフモードへのリモート再起動 | はい、Windows エンドポイント | クライアント側からは不可 | リモートデスクトップから再起動 |
| リモート側のセットアップ | Host またはフルクライアントのインストール | リモート デスクトップを有効化。 Pro、 Enterprise、 Education、または Server のみ(Home を除く) | クライアントアプリ、Windows でポータブル |
| セッション中の管理者権限昇格 | まず Windows 認証を有効にする必要があります | セッションでネイティブ | 管理者アクセスをリクエスト はツールバーから |
よくある質問
次を使用します: 操作、リモート再起動、セーフ モードで再起動 は Windows エンドポイントのセッション ツールバーから使用します。TeamViewer のマニュアルでは、このオプションはネットワーク ドライバー付きのセーフ モードでマシンを再起動すると明記されているため、ネットワーク スタックは存在するはずです。注意点はその一段下にあります: FixMe.IT のドキュメント によれば、一部のデバイスでは Windows 10 が セーフ モード でネットワーク機能を完全に無効化します。これは Microsoft による制限で、どのリモート ツールでも制御できません。リモート アクセスに頼ってセーフ モードから戻す前に、セーフ モードでマシンがインターネットに到達できることを確認してください。
プレブート認証が構成されている場合はそうなります。というのも、Windows が起動する前に、マシンは BitLocker の PIN または回復キーのプロンプトで待機するからです。その時点ではサービスは何も実行されていないため、リモートツールは到達できません。BitLocker は別の側面でも影響します。というのも Automatic Restart Sign-On がそれに依存しているからです。 ConfigAutomaticRestartSignOn ポリシーは BitLocker が有効で一時停止されていない場合、Microsoft が Enabled と呼ぶモードが既定になります、管理対象デバイスでは TPM 2.0 と SecureBoot に加えて BitLocker が必須です。TPM のみの認証は双方の要件を満たす設定で、ARSO のために BitLocker を有効のまま保ちつつ、起動を妨げるプレブートのプロンプトを表示しません。
バージョン更新を行うとアプリケーションはいったん終了して再起動され、再起動とまったく同様にランダムパスワードが再生成されます。セッション自体は問題ありません。TeamViewer のドキュメントには、更新後も自動的にリモートコンピュータへ再接続されると記載されています。問題になるのは次回の接続時で、書き留めておいたパスワードがもう使えなくなっているときです。個人用パスワードを設定するか Easy access を実行する前に Remote update。
そうなることがあり、その変更は必ずしも恒久的ではありません。あるユーザーは インストール ID が変更されたと報告 しており、そのマシンにはすでにライセンスが割り当てられていました。Windows 10 May 2020 Update の直後のことで、3 回目の完全再起動とさらにもう一度 Windows の更新を行った後に、元の ID が自然に戻ってきました。スレッド内の 2 人目のユーザーも同じ現象を確認しています。無人でアクセスするあらゆるデバイスでは、機能更新の前に現在の ID を控えておいてください。もし変更された場合は、ライセンス移行チケットを使う前に、もう一度完全な再起動サイクルを実行してください。というのも、新しい ID のために新規エントリを作成した 3 人目のユーザーは、セッションを離れた途端にそれが機能しなくなったことが判明したからです。
インジケーターが緑に変わった瞬間ではなく、デバイスがしばらくオンラインになっている程度の十分な時間という意味です。TeamViewer はここでしきい値を公開していないため、以下を運用上の目安として扱ってください。通常のデスクトップでは15秒、暗号化済みまたはドメイン参加済みのノートPCでは約90秒に近く、そこで処理される グループ ポリシー は起動時に処理されます。遅延が生じる理由は、リモートソフトウェアがセッションを提供できるようになる前に TeamViewer のサーバーに登録されるためで、インジケーターは実際の準備完了より先行します。


