Tagged: リモートデスクトップ

解決手段が見つからない

Radeon VIIを使った旧メインPCをリモートデスクトップ接続で繋げる問題。

色が破綻

この話題そのものは当Blogでも数回書いているが、都度解決策が見つからないという話に落ち着いて、一向に解決に向かう感じがない。
普通、何か問題が起きた時、その問題をキーワードにネットで検索をかけると、大凡似たような問題の記事が見つかるのだが、本件に関して言うと中々見つからない。
「リモートデスクトップ接続色がおかしい」というキーワードで検索すると、確かに色味に問題があるリモートデスクトップの話は出てくるには出てくるが、完全一致する問題はほぼ出てこない。
今回もまた調べて見たが、解決に至る記事はなく、1件だけ同じ問題を提起している記事にぶつかった。

リモートデスクトップの表示の色がおかしいです。
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11269649516

既に回答受付が締め切られたものだが、私の症状と酷似している問題である。
実際、私もクライアント側で画面の色のbit数、画面解像度などを変更してみたが、どれも結果は変わらず、色が反転？モアレ表示になってしまう。
比較的、誰でも起きそうな問題だと思うが、ここまで酷い色変更が起きるケースはあまりないようである。
何がキッカケでこのような問題が起きるのかすら、よく分かっていない。
ただ、私が経験した事で言うと、Radeon VIIを搭載している時に発生し、GeForce RTX 3070Tiに切替えた時は正常表示された、という事である。
そうなると、問題はAMD製GPUではないのか、と考えてしまうのだが、この話も確実性が高そうというだけで、確定ではない。
とにかく色が破綻していて、文字も読めないというのが私の症状なので、リモートデスクトップ接続としては利用できるレベルにない。

Radeon Driver

ここで一つ気になるのは、やはりRadeonで発生してGeForceでは発生していないという事実である。
となると、Radeon Driverの機能が何かしら影響を与えている可能性を疑わなければならない。
Radeon Driverに関する拡張機能は、現在はAMD Software Adrenaline Editionというソフトウェアに統合されているが、Radeon Driverをインストールする時には、これら拡張機能のソフトウェアも大凡インストールする事になる。
実際、私も旧メインPCにインストールしていたので、このAMD Software Adrenaline Editionを疑う事で、何かしら解決の糸口が見つかるかも知れない。
というのも、このAMD Software Adrenaline Editionには色覚障害者向けにゲーム内の色を調整したりする機能なども内包されているため、何かしら悪さをしている可能性があるのである。
また、ドライバインストール時にゲーム最適化やストリーミング関連の機能をオフにできる「Minimal Install」が選べるようになっているので、これでドライバのみをインストールしてみるという手もある。
不必要な機能をそぎ落とし、シンプルな形で再現するかを確認できれば、問題を回避できるかもしれない。

Radeonだからダメなのか？

リモートデスクトップ接続が出来てもコノ問題は解決しなかった。

やりきる前にやり直し

昨日も記事にしたが、MicrosoftアカウントでセットアップしたWindows11 Proだと、このPCで設定した共有フォルダに外からアクセスさせようとしてログインできないという問題がとてつもなく深刻な問題になるという事が発覚し、挙げ句、リモートデスクトップ接続においても同じようにログインできないという問題がとても大きかったので、改めてローカルアカウントでWindows11 Proを動作させるべく、OSをリセットし初期化する事にした。
やり方は「設定」の中の「回復」機能に入り、その中の「PCをリセットする」からリセットを開始するだけ。混乱を防ぐため、全てのデータを削除してのリセットにした。
現時点で、まだ元の環境の20％ほどしか復帰させていなかったので、それならばと思い、一気にWindows11のセットアップ前まで戻ることにしたのである。
OSの設定をクリアするのに、今までの保存データを全てクリーンアップしてからの再構築を選んだので、インストールが完了するまで30分ほど係ってしまったが、クリーンアップしなければおそらく10分ちょっとで完了するのではないかと思う。
…以前と違って初期化そのものがとても速くなったのは、OSが進化したというだけでなく、ハードウェアの進化によるところも大きいのだろう。

今度はローカルアカウントで

OSを初期化する目的は、ローカルアカウントでOSの初期設定をするため。
なので、再インストールが完了した後の設定は「職場または学校用に設定する」を選択、サインインオプションで「代わりにドメインに参加する」を選択すると、ローカルアカウントの作成が始まった。

最初からこれが判っていれば…と後悔しても始まらない。
とりあえずこのローカルアカウントで、必要最低限の設定を進めていく。
ここで気づいたのだが、WebブラウザからMicrosoftアカウントにログインした時ぐらいだろうか、設定していたWindows11のOneDriveがローカルアカウントのまま利用できるようになった。
…これ、Microsoftアカウントでログインする必要あるのか？
という疑問が浮かんだので、現時点ではローカルアカウントのまま、設定を進めていく事にした。
ローカルアカウントだと、共有フォルダへのログインやリモートデスクトップ接続に何ら問題が出てこないので、思った通りに他PCと連携ができる。
もちろん、Windows11はローカルアカウントのままでも、Microsoft 365からOfficeのインストールも問題なくできる。
OneDriveが使えて、Officeが普通に使えるという状況で、それ以上にMicrosoftアカウントが必要な状況というのはちょっと考えにくい。このままで良いんでなかろうか？
実際には、Microsoftアカウントにしておいた方がよいのだろうが、必要性という意味で考えると十分なんだよなぁ。

リモートデスクトップ問題、解決

原因は…考えたくないがRadeonにあった？

ビデオカード交換をしたので

以前当Blogで、自分のメインPCをリモートデスクトップ機能を使ってノートPCで操作しようとした際、その画像の色がとんでもない配色になり、モアレ状態になった事を記事として挙げた事があるが、その問題は実はまだ解決していなかった。
原因が何にあるのかサッパリわからないままで、予想としてはメインPCはその解像度が3,440×1,440なので、映像データが正常にリモートPCへ届いていないのではないか？と考え、ビデお回りのリモート機能の調整で解決できるか、試行錯誤をしたりしていた。
結果的にはそれら対策は何の効果もなく、結局映像が乱れる原因はわからないままだった。
その後、解決の糸口が全く見えなかったので、ノートPCでメインPCをリモート操作する事を諦めていたのだが、先日Radeon VIIからRTX 3070 Tiにビデオカードを交換、グラフィックドライバもクリーンインストールして入れ替えたので、念の為、もう一度リモートデスクトップ機能で同じ現象が起きるか、昨日テストしてみた。

原因はRadeon？

以前と同じ手順でメインPCを対象にリモートデスクトップのアプリケーションを立上げ、接続を開始すると…何と、以前はあれだけ色がオカシかった画面が、正常に表示されているではないか！
特に何かリモートデスクトップの設定を変えた訳ではない。唯一変えたのはビデオカードとそのドライバだけである。
と言うことは、AMDのドライバとRadeonがあのオカシな現象を引き起こしていた原因という事になる。
ナンテコッタ…。

どうしてもわからない

リモートデスクトップの画面カラーが合わなくて色が破綻した画面しか表示されない。

16bit？ 24bit？ 32bit？

先日購入したDellのInspiron 14 5420にウチで使用しているメインPCをリモートデスクトップで接続して表示させると、どうしても画面のカラーが合わないのか、色がオカシクなり、正常に表示されない。
Inspiron 14 5420を購入した時の当Blogの記事にも同じ事を書いたのだが、その後、いろいろと試して何とか普通に使えないかと試行錯誤していたのだが、結局何をしてもこの問題が解決できる見込みがなかった。
ひょっとして購入したInspiron 14 5420が故障しているのか？とも思ったが、ウチのメインPC以外のPCをリモートしてみたところ、正常にリモートでき、画面のカラーも正常に表示されたのだ。こうなると、問題があるのはウチのメインPCと言うことになる。
デスクトップの色合いという事は、色深度があっていないという事だろうか？と思い、リモートの設定で表示する色を15bit、16bit、24bit、32bitといろいろ切替えて接続してみたが、結局どの設定でも色合いの異常は変わらなかった。
ちなみに、リモートデスクトップの画面以外の、ノートPCのデスクトップは普通の色合いなので、リモートデスクトップで表示しているリモート先のウィンドウだけが色合いがオカシイという状態である。
つまり、どう考えてもInspiron 14 5420は正常に動作していて、リモートデスクトップの対象となっているメインPC側の問題で、このような問題が起きている可能性が高い。

デュアルモニタが問題なのか？

問題を特定する為に、Inspiron 14 5420でリモートデスクトップを試した接続先の状況を一度整理してみる。
すると、Inspiron 14 5420で問題無く表示できているリモートデスクトップ先の他のPCは、全てシングルモニタの構成だという事がわかった。
つまり、私のメインPCのみデュアルモニタ構成だという事。しかも、その2枚にモニタは、共に色深度が異なるという事に気がついた。
34インチのウルトラワイドモニタは8bit、WQHDモニタは10bitという違いがある。
リモートデスクトップにおいて、デュアルモニタのPCをリモートする時に、接続しているモニタの情報と同じものをリモート先に出力しているとも思えないが、もしリモート先のビデオ設定がこれらの情報に左右されるとするならば、確かに問題が発生する可能性はある。
リモートデスクトップという機能における、ビデオ出力がどのような設定によって表示しているのかはわからないが、2枚のモニタの情報がリモート先に影響を与えているなら、一度メインPCのモニタを1枚に絞ってテストしてみてどういう状況になるかを確認した方がよいかもしれない。

リモートデスクトップ、その後

先日、会社PCのリモートデスクトップ機能を利用ができなかった、その続き。

リモートできなかった理由が判明

当Blogで、私の会社で使用しているPCとの間でリモートデスクトップ機能が利用できなかった事を記事にした。
もともと、私自身にロクな知識がない、という事が原因でもあるような話もしたし、他の人の環境ではリモートデスクトップ機能が利用できたのに、私が使用しているPCだけできなかった、という話もした。
その後、いろいろと設定を見直したのだが、コレと思える原因がなかなか見つからなかったのだが、一つだけ、ある可能性を考えて試す事にした。
その可能性というのが、私が会社のPCにインストールしているセキュリティソフトである「ESET Internet Security」というソフトのファイアウォール機能である。
Windows標準のリモートデスクトップ機能を使っているので、まさかコイツがプロトコルをブロックしているとは考えてはいなかったのだが、可能性としてもしコイツがブロックしているようなら、コイツに穴を開けてやればできるのではないか？と考えたわけである。
ESETの「設定」の中に「ネットワーク保護」というのがある。その中に「ファイアウォール」という項目があるのだが、コイツの右側にある車輪マークをクリックすると、サブメニューに「設定」というのがあるので、それを選ぶ。
すると、ファイアウォールの設定画面が出てくるのだが、この中の「詳細」という部分を選ぶと「ルール」と「ゾーン」というのがある。
「ルール」は、ファイアウォール機能を働かせるためのルールを設定するところで、今回はコレを利用する。
「ルール」の右横に「編集」というリンクがあるので、そこに入ると、ファイアウォールによって通信を遮断させたり、許可したりするルールのリストが表示される。
何もルール設定していなければ、ここは何も書かれていないのだが、今回はここにリモートデスクトップの許可を追加してやる。
左下に「追加」とあるので、ここからルールを追加する。
ルールの編集画面で、一般タブにはそのルールの名前と、その方向がPCの内側に向かうものなのか、それとも外側に向かうものなのか、またルールが許可なのか遮断なのかを選ぶところがある。プロトコルはTCPおよびUDPのままで問題ない。
まずルールの名前をわかりやすく「リモートデスクトップ」とし、方向は「内向き」、アクションは「許可」とする。
次に「ローカル」タブに入り、ポートは「3389」とする。これはWindowsが標準的にリモートデスクトップで利用するポート番号である。
下にアプリケーションを選ぶところがあるので、ここで、System32フォルダの下にある「svchost.exe」を選ぶ。このプログラムがリモートデスクトップのプログラムである。
これだけを追記してルールの編集は「OK」とする。
すると、ファイアウォールルールのリストに今設定した「リモートデスクトップ」というルールが追加されているハズである。
ESETの設定はこれで終了、あとは電源を入れた状態でリモートデスクトップを実際に遠隔で使ってみるだけである。

あとは電源の問題

先日、実験の為に会社のPCの電源を入れたまま、帰宅した。
なので、休みの今の状態でも会社PCは電源が入った状態である。
早速、先日できなかったリモートデスクトップ機能を自宅で試してみることに。
会社のWindows Serverなどはすぐにリモートデスクトップで操作できるのだが、自分のPCのIPアドレスを入れて再び試してみる。
すると…繋がった！
要するに、先日まで繋がらなかった理由は、ESET Internet Securityというソフトによってソフトウェアファイアウォールがリモートデスクトップ信号をブロックしていた、という事のようである。
その為、このESET Internet Securityでの問題が解決した事で、電源さえ入っていれば、綿も自宅で自分のPCを操作、業務を完全に実施する事が可能という事が実証された。
もっとも、私の場合は技術的問題が出た時の対処として、リモートワークになる可能性はとてつもなく低いワケだが。
また、リモートデスクトップによるテレワークが可能といっても、PCの電源が入っていれば、という前提の話。
本来なら、Wake on LANなどでハードウェアの電源すらもコントロールできるのが望ましい姿なのだが、残念ながらその問題は解決していない。
おそらく、社内に設置されたL2スイッチングハブとL3スイッチングハブを超えてMagic Packetのやり取りをしなければならないので、それが弊害になっているのだろうと思われる。
また、先日もちょっと書いたが、IPv4とIPv6の設定の問題というのもある。これらが無事解決しない事には、ハードウェアを含めたリモート環境の構築は実現させる事は不可能だろう。

まだまだ理解が足りない

テレワークが進む一方、私の知識はそれに追いついていない。

ITリテラシーが低い状況で

勤め先でリモートワークが進み始めた。IT担当として、それらの対応に日々追われる事となり、本来の業務は別にあるにも係わらず、コチラの作業ばかりを行う羽目に遭い、私の業務効率が著しく低下しはじめている。
私自身、PCそのものに関して素人だとは思わないが、特別何かカリキュラムを学んだとかそういうのではなく、昔からの経験でしかその知識を得ていないところに、いよいよもって本格的なハードウェア、ソフトウェア、ネットワーク、セキュリティ等の対応を迫られるという状況に、その難しさを実感し困惑するばかりである。
社内のPCに、特定のアプリケーションをインストールしていて、それでないと業務が実施できない、という状況でリモートワークが必要になった場合、やはり使える技術としてはリモートデスクトップ機能という事になる。
プログラム開発などでは昔から使われている手法だけに、そうした業界にいる人であればもはや当たり前と言える機能ではあるが、ITに疎い地方の小規模製造業ではその発送に至るまでに時間がかかる。
しかも、遠隔操作ができると知っただけで、まるで魔法を見ているかのような反応をする。
ま、もともとITリテラシーが高くない社員が大多数なので、予想範囲内の反応なのだが、そういう人達に、テレワークに必要な操作や知識を落とし込んで貰うというのは、もはや一大プロジェクトである。
そうした一大プロジェクトを、素人の域を出ていない私が対応しなければならないのだから、このプロジェクトは最初から泥船に乗ったものと言える。大丈夫か？

できる環境とできない環境

いろいろ愚痴も沢山出るのは仕方が無いとは思っているが、今ひとつ、わからない事がある。
それは、VPN環境でリモートデスクトップ機能が使える人と使えない人がいる、という事である。ちなみに使えない人というのは、私である。
もちろんOSがWindowsのProでないと機能そのものが使えないと言うことはわかっている。
また、BIOSなどの設定が変わっていれば使えない可能性がある事もわかっている。
だが、なぜだか私の環境だけでリモートデスクトップ機能が使えないのである。
各家庭に設置されているネットの環境、つまりルーターなどにも違いがあるので、現時点で使えないのが私だけ、という事であり、この先、他にも使えない人が出てくるかも知れない。
この原因をいくら探しても、特定できずにいる。
ひょっとして、私が外部にいる間に、社内の私が使用しているPCの電源が落ちるのかも知れない…そう思い、今度はWake on LANの設定をしてみるが、Wake on LANすら機能しない。
VPN環境だとWake on LANはできないのだろうか？

テレワーク

いよいよ、私の勤め先でもテレワークへの対応を本格的に乗り出した。

重い腰が上がった

私は、そんなに知識もなくまた技術もないのに、勤め先のシステム管理者などというものをやっている。
それ故に、サーバの運用やメンテナンス、通信機器の設定管理などIT関係のいろいろな業務を通常業務と併行して行っているのだが、オミクロン株の本格的な広がりから、勤め先もようやく本格的なテレワークへ乗り出す事となった。
今まで、限定的にリモートワークが可能な状態は作っていたものの、予算の関係などいろいろな障害から、本格的なテレワークという動きにはならなかった。
ところが、ここ最近になって今までより感染拡大が大きくなると、そうも言っていられない。そう判断したのか、ようやくテレワーク環境の構築を急げというお達しがきた。
正直、遅いよ…とも思うが、やらないよりはマシ、という事で、現状可能な範囲でいろいろな実験を開始した。

基本はある

私の勤め先は、富士フィルムのBeatという、不正アクセス対策のハードウェアファイアウォールを導入している。
これを導入する時も随分と上層部を説得したのだが、これを投入していた事で、50人までは外部から社内サーバへアクセスできる事がわかっている。
実際、私も自宅から社内へアクセスできる状況にしていて、以前から限定的に外部からのアクセスが必要な人にこの機能を解放していたのだが、何分50人までという限定数の為、今回のリモートワークに関して、その50人を選出しなおす、という事となった。
リモートワークが特に必要な人、または現場にいなくても問題のない人、という人達が優先的になるのだが、それによってファイルアクセスに関してはリモートが可能になる。
だが、問題は社内アプリケーションを使用しないといけない、という人たちである。
この場合、社内のPCをリモートアクセスする事で解決できるのだが…このリモートアクセスで躓く事が多々ある。
実際、私は会社から支給されているPCに自宅からリモートアクセスしたのだが、リモートできない、という結果である。
自宅からファイルサーバを管理しているサーバにはリモートアクセスできるのに、自分のPCにアクセスできないというのも変な話である。
で、いろいろ探っていく内に重要な事を思い出した。