はじめに
先日、DaaS環境で利用しているSKYSEA Client Viewでこのようなことがありました。
- 管理画面からクライアントのSKYSEA Client Viewを指定した時刻まで一時停止させる機能を試したところ、なぜか指定した時刻になっても再開されなかった。
- 一部のログがUTC(協定世界時)で記録されていました。
しばらく思い悩んだのですが、調べたところ、「タイムゾーンリダイレクト」という機能の影響でした。そこで、今回はこのタイムゾーンリダイレクトについてご紹介します。
タイムゾーンリダイレクトとは
今回の原因になったタイムゾーンリダイレクトは、1台のサーバーに複数ユーザーが同時にログオンして利用するSBC（Server Based Computing）と呼ばれる環境や、Azure Virtual DesktopなどのDaaS環境で広く用いられている機能となります。
リモートデスクトップで接続した際に、サーバーのシステム時刻ではなく、リモートデスクトップ元のPCの時刻をユーザーに対して表示する機能で、クライアント側のタイムゾーンをリダイレクトするため、タイムゾーンリダイレクトと呼ばれています。
この機能によって、タイムゾーンの異なる場所から同じサーバーにログオンした際も、利用者ごとにそれぞれ適切な時刻を表示させることが可能になるというメリットがあります。
タイムゾーンリダイレクトのデメリット
タイムゾーンリダイレクトは大変便利な機能なのですが、時刻を扱うアプリケーションにおいて、サーバーのOSが動作に使っている時刻と、実際に利用者から見えている時刻が異なるため、思った動きにならないことがあるというデメリットが存在します。
SKYSEA Client Viewもログ管理ソフトウェアとして時刻を扱うため、タイムゾーンリダイレクト機能のこのデメリットの影響を受けてしまいます。
今回お問い合わせをいただいた環境では、サーバーのシステム時刻はUTC（協定世界時）なのに対し、タイムゾーンリダイレクトによって見かけ上の時刻はJST（日本標準時）になっていました。
SKYSEA Client Viewの機能は多くがOS側の時刻を参照して動作するため、このような環境では、一部のログデータがJSTではなくUTCで記録されてしまったり、サービスの一時停止の再開時刻がJSTではなくUTCでセットされたりしてしまいます。
SKYSEA Client ViewはOS側の時刻を参照するため、OS側のシステム時刻をJSTに変更することで、こちらの事象は回避できます。
まとめ
タイムゾーンリダイレクトは、時刻を扱うソフトウェアとの相性というデメリットがある一方、海外拠点や海外出張先など、タイムゾーンの異なる地域からもシンクライアント環境を利用したいといった場合には非常に便利な機能となっています。
こちらはあくまで参考情報となるため、詳細は公式ドキュメントをご参照いただければと存じますが、筆者の検証環境では、「リモートデスクトップセッションホスト」機能を有効化したWindows Serverで、次のグループポリシーを「有効」にすることにより検証ができました。
- 「コンピューターの構成」＞「管理用テンプレート」＞「Windowsコンポーネント」 ＞「リモートデスクトップサービス」＞「リモートデスクトップ セッションホスト」＞「デバイスとリソースのリダイレクト」内にある「タイムゾーンリダイレクトを許可する」
事前検証などを通じてメリットとデメリットをご確認いただき、ご利用についてご検討いただくのも手段の一つかと存じます。
今回の記事は以上となります。ご参考になりましたら幸いです。
