一般的にVDIは、同じ業務を行う社員向けにいくつかのマスターイメージを作成した仮想マシンを大量に展開する形が非常に多いです。
しかし、業務によっては特定の人しか利用しないアプリケーションもあることから、それらは、カスタムのマスターを作成したり、そのアプリケーション利用者専用の仮想マシンを手動で作成し1対1で割り当てるケースなどもあります。
今回はこの後者である、特定のアプリケーション用の仮想マシンをメンテナンス中の遭遇した内容です。
こちらの環境では会計担当者が専用の会計アプリケーションを利用しており、会計専用のデスクトップを手動で作成し、専用の会計アプリケーションをインストールしていました。
（いわゆるスタンドアロンアプリケーションとして会計アプリケーションを利用）
導入当初は、Horiozon 6.2で運用しており問題なく動作していましたが、メンテナンスのタイミングで、Horiozn Agent7.4にアップグレードを行い、Windows Updateなどのメンテナンスを行った後、リリースを行ったら、会計アプリケーションからデーターベースに接続ができなくなり、アプリケーションが起動できなくなったという報告を受けました。
アプリケーションを起動すると「データーベースに接続できませんでした」とだけ表示され、ログは特に出力されません。
このアプリケーションは、クライアントが操作するアプリケーションの中にSQLServer 2012 Expressがインストールされており、ローカルホストでアプリケーションとデーターベースが通信をしているアプリケーションでした。
ただ、サービスを見てみると、SQLServerのインスタンスは正常起動しており、
SQLServer Management Studioからはきちんと接続でき、DBとしては正しく起動している状況でした。
こうなると、SQLServerのインスタンス名指定間違いや、DBとAPサーバー間のFirewallによる通信制御を考えてしまいますが、そもそもスタンドアロンでの運用ですし、インスタンス名も特に変更をしていません。
ためしに、Horizon Agentをアンインストールしたところ、アプリケーションは何事もなかったように起動しました。
さて、ここで考えられるのは、Horizon View Agentのインストールすることによって、何らかの影響が生じているということです。
長い前置きでしたが、実はHorizon Agentの新しいバージョン（Ver7以降）に関しては、低レベルの暗号化を無効にするレジストリーキーが記載されます。
それは、Horizon ClientとHorizon Agentの間でですよね？と思われがちですが、実はOSに影響を与える部分のレジストリも変更されます。
今回のSQLServer Express 2012は、TLS1.0が必要だったのですが、これがHorizon Agentによって無効化され、アプリケーションがデーターベースと接続できなくなったというのが原因でした。
では、解決方法をお知らせいたします。
レジストリで以下を変更します。
HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥Control¥SecurityProviders¥SCHANNEL¥Protocols¥TLS1.0¥Server
に、以下の値を作成します（すでにある場合は変更します）
Enabled ：1 (DWORD32Bit)
変更をWindowsを再起動すると、アプリケーションは正しくデーターベースと接続できるようになります。
※そのほか、SSL3.0などの制御もこのレジストリから行います。
やや古めなアプリケーションの場合、このようにHorizon Agentのセキュリティ回りの影響を受ける可能性がありますので、その場合このようなワークアラウンドで切り抜けるしかないですね。
もし、SQLServer系のアプリケーション利用で、Horizon Agentをバージョンアップした際にアプリケーションが動作しなくなった場合は、一度確認をしてみましょう。
参考
https://docs.microsoft.com/ja-jp/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs
