概要

Bizrobo!のDesign Studio（DS）で、Desktop Automation Service（DAS）への接続をして開発をすることがあると思います。

いくつかの端末で開発をしていたところ、なぜか初回の接続で毎回タイムアウトしてしまう端末を発見。

ワイヤーシャークやログから通信を追っかけてみたところ、どうやら閉域ネットワーク（閉域網）の環境だと起こる様子。
※補足
閉域環境…インターネットから切り離された独自のネットワーク
参考記事：閉域網とは? 種類やメリット、選び方、セキュリティ対策の方法を解説

これについて調査した結果と、実施した対処方法を書いていきます。

目次

確認できた挙動
対処方法
補足情報
参考

確認できた挙動

Design Studio（DS）とRoboServer（RS）が、Desktop Automation Service（DAS）と初めて通信を行うときに、WindowsはSSL/TLS通信によって証明書を確認しにいきます。
応答がない場合、3～5秒でタイムアウトします。

上記の証明書を確認するときに、DNSでの名前解決も行います。
応答がない場合、こちらは約30秒でタイムアウトします。

それに対して、Bizrobo!側はというと、DSとDASの通信開始して10秒間応答がないとタイムアウトしてしまいます。

つまり、SSL/TLS通信を行う環境でDNSサーバー（ルーター含む）と疎通でき、かつDNSのリクエストが外部通信できない閉域ネットワークの環境では、DNSの名前解決よりもBizrobo!のタイムアウトの時間が先に来てしまい、結果的に初回の接続で毎回タイムアウトしてしまうようです。

この時、証明書の確認自体をさせなければDNSの名前解決もする必要がなくなるため、証明書の確認を無効にするといった方法で回避することができました。

対処方法

グループポリシーより、[コンピュータの構成] - [ポリシー] - [Windowsの設定] - [セキュリティの設定] - [公開キーのポリシー] - [証明書パス検証の設定]を選択。
ネットワークの取得タブから、”これらのポリシーの設定を定義する”にチェックをいれ、”Microsoftルート証明書プログラムで証明書を自動更新する”のチェックを外すことで、閉域ネットワークの環境でも問題なく初回接続できるようになりました。

補足情報

ネットワークが完全に切断されているオフラインの環境の場合、TCPのタイムアウトが先に発生してくれるので、証明書を無効にしなくてもDSとDASが問題なく初回接続できました。（LocalDAでのテスト結果です）
参考：Local Desktop Automationの機能と設定方法について
DNS名前解決は端末でキャッシュされるため、ipconfig /flushdnsでキャッシュを破棄することで、2回目以降の接続でも発生させることができました。

v11.3.0.4とv11.4以降では、Design Studio.confもしくはRoboServer.confに以下を追記することでタイムアウトの設定を最大で20秒まで伸ばせるようです。
参考： Communication defaults between different Kofax RPA (Kapow) components

#DAS Timeout 
wrapper.java.additional.30=-Ddas.timeout.seconds=20

HOSTS、LMHOSTSで「ctldl.windowsupdate.com」を設定しても、特定のURLは設定を無視してDNSを問い合わせてしまうようで、回避策には使えませんでした。

参考

閉域網とは? 種類やメリット、選び方、セキュリティ対策の方法を解説
Communication defaults between different Kofax RPA (Kapow) components