みなさま、ごきげんよう。永瀬です。

今回も、前回に引き続き、2021年02月19日に開催した AA de Knight #7 でお話しした、A2019 の Multiple Users 機能の変更点の整理です。A2019 はバージョンアップによって機能が増えてきていますが、既存の機能もバージョンアップによってサポート対象や動作に変更が発生しているものがあります。その中で、今回は Unattended Bot Runner (UBR) で Bot 実行時の Windows セッションをコンソールと RDP で切り替える「デバイスタイプ」の設定について整理していきます。

AA de Knight #7 ではリリースのタイミング的に A2019.18 での検証結果に基づいてお話ししましたが、現行の最新バージョンとなる A2019.19 での情報に更新しています。

　

□目次

１．A2019.16 でデバイス登録時の新たな設定

２．検証結果　A2019.19 WS2019

３．検証結果　A2019.19 Win10

　

それでは、さっそく見ていきましょう。

　

---

　

１．A2019.16 でデバイス登録時の新たな設定

A2019.16 のリリースノートで、新機能としてマルチユーザーデバイスのサポートが記載されました。上図のリリースノートのスクリーンショット上の赤下線はこちらで引いたものですが、同一端末上での複数同時接続セッションがターミナルサーバー（いわゆる RDS: Remote Desktop Service もしくは RDP: Remote Desktop Protocol です）でサポートされることになりました。

これにより、Bot 実行時のオプションとして、従来のコンソールセッション内での Bot 実行のみではなく、RDP セッション内での Bot 実行もサポートされるようになりました。それに伴い、新しい設定項目も増えました。

詳細は以下のリリースノートを参照してください。

Enterprise A2019.16 Release Notes

ここでは、関連する設定項目を3つ解説し、Bot Runner デバイス上の既存のセッションの状態に依存して Bot の実行がどのような影響を受けるかを検証した結果を説明します。

　

一つ目の設定項目は、［デバイスタイプ］です。デバイスの新規登録時に上図のダイアログを見た方も多いと思います。ここで Device Type の設定項目があり、「Single User」か「Multiple Users」かのどちらかを選択します。

ダイアログ上の説明文からは実際に何を選択しているのかわかりませんが、この設定項目によって Bot 実行時の Windows セッションがコンソールセッションになるのか RDP セッションになるのかが決まります。Single User を選択した場合は、従来通りコンソールセッションで Bot を実行します。Multiple Users を選択して RDP セッションでの実行を選択した場合、Bot 実行時には Bot Runner デバイス上で FreeRDP (wfreerdp.exe) を TS (Terminal Service) クライアントとして使用して Bot Runner デバイス自身に RDP 接続をし、その RDP セッション内で Bot を実行します。

デバイスタイプの設定は、（適切な権限が付与されていれば）Control Room の［デバイス］ページから目的のデバイスの詳細ページであとからでも変更することができます。

　

二つ目の設定項目は、［デバイスの資格情報］です。これは従来からある設定項目で、Unattended Bot Runner (UBR) での実行時に自動ログインに使用する Windows アカウントの認証情報（ドメイン名\ユーザー名とパスワード）を設定しておきます。Attended Bot Runner (ABR) でも Bot を実行する Windows セッションを検索するために「デバイスユーザー名」の設定内容を使用するので、デバイスユーザー名の設定は必須です。なお、ABR ではパスワードは設定していなくても動作しますが、UBR ではパスワードの設定も必須です。ここで指定した内容に間違いがあると、Bot の実行がエラーになり失敗します。

自動ログインに関連するその他の項目として、A2019 では、Windows OS 側でログイン前に Ctrl+Alt+Del が必要な設定になっていると対応できません。Windows のポリシーで「対話型ログオン： Ctrl + Alt + Del を必要としない」ポリシーを有効にして、ログイン前に Ctrl+Alt+Del の押下が必要ないようにしておきます。また、A2019 ではログイン前に表示される法的免責条項の画面は、自動的に検出して対応します。設定は常に有効になっているかたちですので、特段の設定は不要です。

　

三つ目の設定項目は、［デバイスセッションの解像度設定］です。RDP セッション内で Bot を実行する場合、その RDP セッションの画面サイズを指定することができます。基本的には、Creator で Bot を作成したときと同じ画面サイズに設定することで、Bot による画面操作が安定して実行できます。また、同じ理由から、Creator での Bot 開発時は、Windows OS の［ディスプレイ］の設定で［拡大縮小とレイアウト］の［テキスト、アプリ、その他の項目のサイズを変更する］（いわゆる「DPI 設定」）は「100%」にしておくことをお奨めします。

上図の設定画面のスクリーンショットから読み取れるように、既存の RDP セッションが存在した場合にここで指定した画面サイズを強制するかどうかを指定できます。また、この設定値は CR 全体で統一して指定することも、デバイスごとに個別の設定を許可することもできます。

　

２．検証結果　A2019.19 WS2019

この記事は、A2019.19 で環境を構築して検証しました。上図は、検証に使用した環境の詳細です。

　

UBR として Bot 実行しようとする Bot Runner デバイス（Windows Server 2019 RDS サーバー）上に既存のセッションが存在した場合に、デバイスタイプの設定によって動作に違いがあるかどうかを確認しました。結論としては、Multiple Users を選択して RDP セッションで実行しようとした場合、同一ユーザーのコンソールセッションが存在しているとエラーになりました。ただし、この場合は監査ログに「別ユーザーのコンソールセッションがあるからエラーにする」旨が記録されるので、製品として意図した動作ということのようです。それ以外の場合は基本的に Bot が正常に実行できました。

A2019.18 までは切断セッションに対する動作がおかしかった（エラーになって実行できなかった）のですが、A2019.19 で修正されて正常に動作するようになりました。

余談ながら、表では「アクティブ」と「ロック」で列を分けていますが、Windows セッションの状態（Session State）としては両方ともアクティブ（Active）になります。ロックというのは、セッションはアクティブでデスクトップがロック状態ということになります。

　

上図のフローチャートは、Windows Server 2019 を Bot Runner デバイスとして、Single User （コンソール）で UBR を実行しようとした場合の詳細です。Automation Anywhere 社の公式ドキュメントに公開情報が見つからないので、あくまでも検証による推定です。

• Bot が起動すると、まず［デバイスの資格情報］に設定したユーザー名の既存のセッションが存在するかどうかを検索します。

↓

• アクティブなセッションが見つかると、ロック状態かどうかをチェックし、ロックされていればロックを解除して Bot を実行します。
• セッションが見つからない場合は［デバイスの資格情報］に設定された Windows アカウントでログオンし、Bot を実行します。
• 切断セッションが見つかると、RDP セッションからコンソールセッションにして Bot を実行します。この場合だけ、RDP セッションがコンソールセッションに変わってしまい、RDP セッションには戻さないため、Bot 実行開始前と同じ状態に戻りません。

　

赤字で「失敗」としている個所は、［デバイスの資格情報］に設定した情報が間違っている場合に発生します。また、実際には、アクティブなセッションが見つかってロック状態ではなくても、［デバイスの資格情報］に設定したパスワードが間違っていると UBR ではエラーになります。

　

今度は、Windows Server 2019 RDS サーバーを Bot Runner デバイスとして、Multiple Users（RDP）で UBR を実行しようとした場合の詳細です。繰り返しになりますが、Automation Anywhere 社の公式ドキュメントに公開情報が見つからないので、あくまでも検証による推定です。

Single User の時との違いは、切断セッションでも想定通りに正常に Bot が動作する点と、前述の通り同一ユーザーのコンソールセッションが存在するとエラーになる点です。

　

３．検証結果　A2019.19 Win10

続いて、Single User OS の Windows 10 を Bot Runner デバイスにした場合の動作です。おさらいとして、以前のバージョンである A2019.13 で検証した際の情報で、従来の動作をご確認ください。従来はコンソールセッションでの動作しかサポートされていないため、デバイスタイプが Single User の場合に該当します。以前は同一ユーザーの切断セッションが存在する場合の動きが妙でしたが、基本的にはすべての場合で正常に Bot が実行できました。

Single User OS である Windows 10 を Bot Runner デバイスとした場合も、基本的には Windows Server 2019 の場合と同様です。RDP (Multiple Users) で接続しようとした場合に別のユーザーのアクティブな Windows セッションが存在する場合は、OS 側の制限によりログインできない（「別のユーザーがログインしています」のダイアログがでて OS によってブロックされる）点が違いとなりますが、Single User OS であることを考えれば当然ということになります。

　

---

　

今回はここまで。Bot 実行時の Windows セッションがコンソールセッションなのか RDP セッションなのかによって動作に違いが出てくるので、Bot がうまく展開されず動かない時に今回の内容が状況整理の足しになれば幸いです。

また次回まで、みなさまごきげんよう。