2020.10.1
公開日: 2020 年 10 月 28 日
新しい Orchestrator では、新規に作成するテナントに対してクラシック フォルダーを使用できなくなり、新規ユーザーと新規デプロイには既定でモダン フォルダーが設定されるようになりました。
-
既にモダン フォルダーを使い慣れているユーザーにとって、この変更にはさまざまな利点があります。階層内や階層間でのフォルダーの移動や、フォルダーおよび関連エンティティの削除、そして既定のフォルダー ロールに関連付けられた権限の変更を簡単に行うことができます。
-
自動化の準備をもっと簡単に行えるよう、新規テナントでは個人用ワークスペースが既定で有効化され、すぐに使える 5 つのロールが自動で作成されます。モダン フォルダーのみのアプローチへの切り替えに伴い、既定のモダン フォルダーのロールに関連する権限を更新しました。以下のリンクからご確認ください。
|
ロール | |
|---|---|
|
Tenant Administrator |
|
|
Allow to be Folder Administrator (以前の Enable Folder Administration) |
|
|
Folder Administrator |
|
|
Allow to be Automation User (以前の Enable Running Automation) |
|
|
Automation User |
|
-
管理者ユーザーにはテナント レベルで Tenant Administrator、Allow to be Folder Administrator、Allow to be Automation User、Administrator のロールが付与されます。
-
フォルダー管理者の属性とテナント管理者の属性を明確に区別するために、フォルダーを対象とするロール (Allow to be Folder Administrator と Allow to be Automation User) からロボットの管理権限を削除しました。ベスト プラクティスとしては、ロボットに係る権限で構成される別のロールを作成し、そのロールを必要なユーザーに対して制御された方法で割り当てることをお勧めします。
権限モデル
-
アクセス制御をさらにシンプルにするために、「テナントから継承」の割り当てモデルを非推奨としました。これまで「テナントから継承」モデルを使用していた既存のモダン フォルダーは変換され、各ユーザーに対してテナント ロールがフォルダー レベルでも付与されます。
ロールの変換について例を挙げて説明します。たとえばペトリーナさんが Finance と HR のフォルダーで作業をしており、これらのフォルダーはこれまで「テナントから継承」の権限モデルを使用していたとします。この場合、テナントから継承されたロールはフォルダー レベルでフォルダーごとにユーザーに割り当てられます。その結果、ペトリーナさんは Finance と HR の両方のフォルダーでロールを割り当てられ、テナント レベルでもこのロールが保持されます。
クラシック フォルダー
まだクラシック フォルダーを使用している方もご心配無用です。既存のデプロイをアップグレードしても、クラシック フォルダーのサポートは失われません。また、移行ツールを追加し、素早く簡単にモダン フォルダーに移行できるようにしました。
DefaultFolderIsClassic パラメーターは Features.ClassicFolders.Enabled に置き換えられました。パラメーター Features.ClassicFolders.Enabled は既定では非表示で、既定値は false です。
パッケージを個別に保持しながら社内で責任を委任できるよう、第 1 レベルのフォルダーを作成する際に専用のパッケージ フィードを作成できるようになりました。方法についてはこちらをご覧ください。
フィードへのアクセス権は、フォルダー用の新しい権限セット「フォルダー パッケージ」で制御できます。すべてのサブフォルダーは、ルートの親からパッケージ フィードの設定を継承します。
フォルダー パッケージ
個人用ワークスペースには、既定で専用のパッケージ フィードが作成されます。パッケージのデプロイは非常に簡単で、ワークスペースにパッケージを追加すると、それがワークスペース内で自動的にプロセスとしてデプロイされます。
マシン テンプレート
今回のリリースからは、マシン テンプレートをユーザーが管理する必要がなくなりました。このため、不要な手間が省け、開発者はワークスペース内ですぐに作業を開始し、オートメーション プロジェクトをパブリッシュしたり、Orchestrator からデバッグ目的でジョブを開始したりできます。
個人用ワークスペース以外に別のフォルダーでも作業をしているユーザーは、マシン テンプレートの Orchestrator デバッグ機能を利用できます。この機能を利用するには、作業対象のフォルダー (そのユーザーが割り当てられているフォルダー) にマシン テンプレートを割り当てます。
簡易版の UI プロファイル
自動化を始めたばかりのユーザー向けに、個人用ワークスペース用の簡易版の Orchestrator UI プロファイルを追加しました。この UI には、ワークスペースで利用できる機能のみが表示されます。UI プロファイルについて詳しくはこちらをご覧ください。
今回のリリースでは、個人用ワークスペースの管理者および業務担当者のためのさまざまな改良を行い、ワークスペースの管理における主要な機能を提供します。
-
すべてのワークスペースを一元化された場所から確認できるようになりました。また、開発者のワークスペースのコンテンツを探索して日々の業務を手助けできるようになりました。
-
使用されていないデータを簡単に整理できるようになりました。ほとんどアクティブでないワークスペースや、従業員が組織を離れたために孤立しているワークスペースを素早く識別し、専用のページ [個人用ワークスペース] で簡単に削除したりフォルダーに変換したりできます。このクリーンアップ作業は管理者の裁量で行うことができ、余計な手間もかかりません。
-
複数のユーザーに対して個人用ワークスペースを一括でシームレスに有効化できる機能を追加しました。この操作は [設定] ページの [個人用ワークスペース] セクションから行います。管理者がワークスペースを一括で有効化できる対象ユーザーは、テナント内で特定の Attended ライセンス プロファイルを使用しており、まだワークスペースのないユーザー全員です。
個人用ワークスペースについて詳しくは、こちらをご覧ください。
特定のマシンでジョブを開始
今回のリリースでは特定のジョブを開始するホスト マシンを選択できるようにしました。これにより、デバッグ機能がさらに向上しました。ジョブについて詳しくはこちらをご確認ください。
ローカル ユーザー向けの Unattended ロボット
Unattended ロボットをローカル アカウントとして機能させる場合に必要な情報を、そのアカウントの Windows ユーザー名およびパスワードのみとし、必須の識別子からホスト マシンを除外しました。このため、ローカルの Windows ユーザーが複数のホスト マシンに配置されていても、無人オートメーションをより簡単に行えるようになりました。
.\LocalUser1 を使用します。この方法を使用すれば、Orchestrator のユーザー エンティティ 1 つで、各ホスト マシン上に存在する特定の Windows アカウントを使用できます。
domain\username のままです。
ユーザーごとのアセット
業務のニーズにより的確に応えるため、アセットをロボットごとではなく、ユーザーごとに設定できるようにしました。これにより、実行時に使用する資格情報とユーザーとの正確なマッピングを作成でき、モダン フォルダーでのアセットのロジックが向上します。
同時接続実行の制限
ユーザーが 1 度に複数回ログインできないシナリオに対応するため、同時接続の Unattended 実行を制限できるようにしました。ユーザーが同時に複数のジョブを実行できないように制限できるため、ジョブの割り当てのアルゴリズムを調整できます。
HSM プロバイダーの管理
Unattended ロボットの資格情報を取得するために使用するハードウェア セキュリティ モデルを、Orchestrator のテナントから便利に選択できるようになりました。このため、HSM プロバイダーに関する管理性が向上しました。
また、ロボット レベルで HSM を設定する必要がなくなり、無人の自動化のシナリオにおける認証操作が効率化されました。
スケーラビリティ、パフォーマンス、セキュリティを新たなレベルに引き上げるため、Orchestrator を .NET Core 3.1 に移行しました。このため、技術革新に対応しつつ、新しいフレームワークの機能を最大限に活用できるようになりました。
ターゲット フレームワーク
TargetFramework を以前の .NET Framework 4.7.2 からサポート対象のターゲット フレームワークにアップグレードする必要があります。資格情報ストアと NLog 拡張機能の両方のターゲット フレームワークは、UiPathOrchestrator.msi インストーラーおよびプラットフォーム構成ツールによって確認されます。詳細については、ドキュメントの「ターゲット フレームワーク」のセクションをご確認ください。
CyberArk の資格情報ストア プラグイン
古いバージョンの Orchestrator では、CyberArk の資格情報ストア プラグインは .NET Core に非対応のライブラリを使用していました。新しい Orchestrator では、CyberArk AIM が付属した CLIPasswordSDK.exe ツールが使用されます。詳細についてはこちらをご覧ください。
プロキシ構成
web.config ではなく、.NET Core で設定するように変更されました。v2020.10 のプロキシ構成についてはこちらをご確認ください。
web.config
web.config から UiPath.Orchestrator.dll.config に移動しました。新しいファイルは以前の web.config ファイルと同じ構造を保持し、ディレクトリも同一です。UiPath.Orchestrator.dll.config に変更を加えた後は、新しい構成が適用されるように Web サイトを手動で再起動してください。
web.config は、IIS が使用する構成を含むファイルとしてのみ再利用されています。アップグレード時には、インストーラーが自動的に構成設定を新しい構成ファイルに移動します。
この変更について詳しくは、こちらをご覧ください。
v2020.10 の web.config についてのドキュメントは、こちらからご確認ください。
v2020.10 の UiPath.Orchestrator.dll.config についてのドキュメントは、こちらからご確認ください。
IIS マネージャー
接続文字列とアプリケーション設定が IIS マネージャーに表示されなくなりました。このため、IIS マネージャーを使用した Orchestrator の接続文字列やアプリケーション設定の編集はサポートされません。構成ファイルを直接編集する必要があります。
NLog ターゲット
Database のカスタム NLog ターゲットを使用する場合、アップグレード中に、プロパティ connectionStringName が自動的に connectionString に変更されます。インストール/アップグレード後に構成ファイルに手動でターゲットを挿入する場合は、新しいプロパティに正しい値を入力して使用してください。詳しくは、こちらをご覧ください。
SignalR と WebSocket
SignalR ライブラリを、古い Robot クライアントに非対応の新しいバージョンに更新しました。WebSocket を使用するため、Robot を v2020.10 にアップグレードすることをお勧めします。ロボットを大規模にデプロイしている場合は、特に高いコスト効果が得られます。
SignalR の固定セッション
SignalR Redis のスケールアウトには、WebSocket 以外のすべてのトランスポートに固定セッションが必要です。ユーザーのロード バランサー上では固定セッションが有効化されていないと想定し、既定では WebSocket トランスポートのみが有効化されています。
SignalR の SQL Server によるスケールアウト
Scalability.SignalR.AuthenticationEnabled は無効になりました。
[キュー アイテムを待機] アクティビティ
v2020.10 より古い [キュー アイテムを待機] アクティビティを使用すると、最大 30 秒の遅延が発生する場合があります。このような問題を避けるには、最新のバージョンのアクティビティにアップグレードしてください。
NuGet インフラストラクチャ
アップグレードのプロセスをシームレスにするために .NET Core への移行を行った結果、さまざまな変化がもたらされました。NuGet プロトコルも改良され、速度と強度が向上しました。Orchestrator を v2020.10 にアップグレードした後は、オートメーションの機能を完全な状態で使用できるように Robot の再起動を強くお勧めします。
内部 NuGet フィードのプロトコルを v2 から v3 に更新しました。
Legacy は NuGet.Repository.Type としてサポートされなくなりました。アップグレード時に、種類が Legacy のリポジトリは、すべて Composite に移行されます。Legacy に関連するアプリケーションの設定はすべて非推奨となり、無効になりました。
Swagger ライブラリ
swagger.json ファイルの生成方法を大幅に変更しました。Swagger ファイル内の API 記述を使用するクライアント ライブラリ ジェネレーター (AutoRest、Swagger Codegen など) に依存している場合、生成されるコードが以前と大幅に異なります。
フォーム POST パラメーターを持つ API
POST 要求は機能しなくなりました。Orchestrator に POST 要求を行う際は、要求本文の JSON に要求パラメーターを含める方法のみがサポートされます。
プラットフォーム構成ツール
Orchestrator v2020.10 には、改良されてより堅牢になったプラットフォーム構成ツールが付属しています。ツールの用途を変更し、Orchestrator のデプロイのさまざまな面で役立つようにしました。最新バージョンではアップグレード前に環境のサニティや準備状況を確認したり、インストール後に複数の操作を実行したりできます。
複数の要件チェックを行うだけでなく、インストール後に行う Orchestrator/Identity Server の証明書や URL の変更プロセスを効率化できます。プラットフォーム構成ツールについてはこちらをご確認ください。
UiPath.Orchestrator.dll.config 暗号化/復号ツール
UiPath.Orchestrator.dll.config) のセクションを暗号化できるようにしました。UiPath.Orchestrator.Setup.ProtectedConfiguration.Console.exe は、aspnet_regiis.exe 上でラップされた CLI ツールです。ツールは、aspnet_regiis.exe に渡されるすべての引数を受け付け、不足している .NET Core の機能を追加します。UiPath.Orchestrator.dll.config セクションの暗号化について詳しくは、こちらをご覧ください。
AppSettings.Production.json 暗号化/復号ツール
AppSettings.Production.json ファイルを暗号化/復号できるツールを追加しました。UiPath.IdentityServerConfigProtector.exe ツールは、Orchestrator のインストール ディレクトリの Identity フォルダー内にあります (C:\Program Files (x86)h\Orchestrator\Identity\Tools)。使用方法についてはこちらをご覧ください。
プロセス制御機能を向上させるため、[常時実行プロセス] オプションを [プロセスの設定] ページに追加しました。このオプションを使用すると UiPath Assistant からプロセスを終了できなくなります。プロセスの管理方法について詳しくはこちらをご覧ください。
分類ステーションを追加し、ドキュメントの分類や分割の結果を人間がレビューしたり修正したりできるようにしました。このため、人間とロボットがもっと協力して作業できるようになりました。分類ステーションは、[分類ステーションを提示] アクティビティを使用すればユーザーの操作によって提示できます。また、長期実行のワークフロー機能を活用し、分類ステーションを Orchestrator の Action Center に統合することもできます。この場合は [ドキュメント分類アクションを作成] アクティビティと [ドキュメント分類アクション完了まで待機し再開] アクティビティを使用します。
Triggers.DisableWhenFailedCount と Triggers.DisableWhenFailingSinceDays を UiPath.Orchestrator.dll.config (以前の web.config) に追加し、トリガーを自動的に無効化できるようにしました。特定の日数の間 (Triggers.DisableWhenFailingSinceDays) 正常に起動できていない状態で、特定の回数 (Triggers.DisableWhenFailedCount) 起動に失敗すると、トリガーが自動的に無効化されます。
これらの UiPath.Orchestrator.dll.config パラメーターについて詳しくは、こちらをご覧ください。
今回のリリースでは Action Center がモダン フォルダーもサポートするようになりました。これまで Action Center の使用はクラシック フォルダーのみに制限されていましたが、今後はフォルダーの種類に関わらず Action Center のすべての機能を使用できます。
また、社内のアクション管理者専用に新しくページを追加しました。このためアクションを一元管理し、ユーザーに対する割り当てが簡単に行えるようになりました。
使用性に関する改良点の中で今回のリリースで特に重要なのは、プロセスに関するものです。パッケージ レベルでのプロセスの更新について詳しくはこちらをご覧ください。
-
プロセス同士の識別や区別を行いやすくするため、関連パッケージを Studio でデザインした際に設定した説明がプロセスに継承されるようになりました。これは手動でデプロイした場合でも、自動で個人用ワークスペースにデプロイした場合でも同様です。また、無制限で自由にプロセスの説明を追加したり、既存の説明を変更したりできます。Orchestrator へのプロセスの追加方法については、こちらをご覧ください。
-
一括更新機能を追加し、パッケージに関連付けられたプロセスをすべてアップグレードできるようにしました。このため、複数のフォルダーで使用されているプロセスを利用可能な最新バージョンのパッケージに簡単に更新できるようになりました。対象のパッケージを選択すると、関連付けられたプロセスのうちで最新バージョンのパッケージが使用されていないものを Orchestrator が検索し、表示します。最新バージョンのパッケージに更新するプロセスを選択すれば、操作は完了です。
a. パッケージの名前
b. パッケージの最新バージョン
c. 最新パッケージ バージョンを使用していないプロセスの数
d. プロセスの名前、現在のパッケージ バージョン、それらが保存されているフォルダー/サブフォルダーのパス
前述した新機能や改良点の他にも、使用性や製品全体の一貫性を向上させるためにさまざまな変更を行いました。このセクションでは、ユーザー エクスペリエンスに関わる更新情報について説明します。
-
Orchestrator ウィンドウのヘッダーの色とロゴを変更する前に設定をプレビューできるようにしました。このため変更を保存する前に設定を適宜調整できます。
-
ユーザー、ユーザー グループ、マシン テンプレートをフォルダー レベルで直接割り当てられるようになりました。この操作は、フォルダー コンテキストの [設定] ページから行えます。
-
マシン キーのコピーやランタイムの編集が、[マシン] ページからだけでなく [フォルダー] ページからも直接行えるようになりました。このため、マシン テンプレートのフォルダーへの割り当て作業が簡単になりました。ただし、マシン テンプレートの実行にはランタイムが必要であるため、マシンをフォルダーに割り当てる際はランタイムを割り当てるようにしてください。
-
Orchestrator の統計情報の概要をもっと使いやすくするために、ホーム ページのジョブのカウンターから対応する [ジョブ] ページに移動でき、移動先のページが適切にフィルター処理されるようにしました。たとえば「実行中のジョブ」に対応するセクションをクリックすると、表示されるページには「実行中」ステートのフィルターが適用されます。
-
[プロセス] ページに、各プロセスに関連するパッケージ名が表示されるようになりました。
-
既定のロールに必要な権限を簡単に追加できるようになりました。
-
ユーザーからのフィードバックをもとに、[設定] ページで利用可能な定義済みのロールの名前をいくつか変更しました。新しい名前と、各ロールに対応する権限について詳しくはこちらをご覧ください。
|
以前の名前 |
新しい名前 |
|---|---|
|
Enable Folder Administration |
Allow to be Folder Administrator |
|
Enable Running Automation |
Allow to be Automation User |
-
今回から、
UiPathOrchestrator.msiインストーラーは Web サイトのホスト名の検証を SSL 証明書のサブジェクトの代替名に対して行い、代替名が見つからない場合にのみサブジェクト名を確認するようになりました。
-
セカンダリ ノードのインストールは、サイレント モードでのみ実行できるようになりました。インストールの際は
PARAMETERS_FILEパラメーターを指定するようにしてください。
-
Azure デプロイで Identity Server が有効な Orchestrator にアップグレードするための移行プロセスを改良し、移行が失敗した場合のロールバック機能を追加しました。
-
テスト ケースを含むテスト オートメーションをパブリッシュすると、プロセスがまだ存在しない場合はプロセスが自動で作成されるようになりました。
-
テスト スケジュールが、前回の実行が完了した場合にのみ新しいテスト実行を作成するようになりました。
-
実行メディアがテスト実行でサポートされ、実行に失敗した際に作成されるスクリーンショットを表示できるようになりました。
-
[テスト ケース] ページで直接テスト セットを作成できるようになりました。
-
外部ツールで作成したテスト セットが API 経由でのみ表示できるようになり、[テスト セット] ページには表示されなくなりました。
-
テスト オートメーション パッケージをアップロードする際の検証を 2 件追加しました。このようなパッケージやパッケージのバージョンを正常にアップロードするには、以下の条件を満たす必要があります。
-
パッケージには少なくとも 1 つのエントリ ポイントが含まれている
- 同一パッケージの異なるバージョン間では、プロジェクトの種類が同じである
-
-
リリース バージョンのフィルター処理およびテスト セットの作成のパフォーマンスを向上させました。
-
テスト セットを作成する際、パッケージをすべての利用可能なバージョンから選択できるようにしました。
-
これまでは、Windows 認証を使用して行われる API 要求の対象は AD ユーザーがプロビジョニングされた最初のテナントに制限されていました。現在は、API 呼び出しを行う際にヘッダー
X-UIPATH-TenantNameを使用してテナントを指定できるようになりました。こちらから例をご覧ください。
-
エンドポイント
/odata/Sessions/UiPath.Server.Configuration.OData.GetMachineSessionsにGET要求を行ってマシン セッション ID を取得できるようになりました。
-
「終了中」ステートのジョブが溜まらないようにする機能を数点追加しました。まず、強制終了のコマンドでジョブを「終了中」ステートに移行できるようにしました。さらに、
Jobs.TerminatingJobsTimeoutとJobs.TerminatingJobsCleanupCronのパラメーターを追加し、設定に応じてジョブのステートを「終了中」から「失敗」に移行できるようにしました。このため、ジョブのクリーンアップの方法を必要に応じて調整できるようになりました。既定では、クリーンアップのバックグラウンド ジョブは 3 時間に 1 度実行され、少なくとも 1 日間「終了中」ステートに留まっていたジョブのみが「失敗」ステートに移行されます。パラメーターの設定方法についてはこちらをご確認ください。
-
アクションの保存に対する Webhook (
task.saved) を追加し、アクションが完了前に保存された場合に通知が送信されるようにしました。
-
ログの生成元のホスト マシンの名前でログをフィルター処理できるようになりました。この操作は [ログ] ページの [マシン] フィルターで行うことができます。新しいフィルターは Elasticsearch に格納されているログに対しては機能しますが、データベースに格納されているログについては新規のログ エントリに対してのみ機能します。
-
Orchestrator で起きているすべてのイベントについて通知を受け取れるよう、フォルダーおよび個人用ワークスペースのアラートを追加しました。アラートについてはこちらをご確認ください。
-
Robot が v2020.10 以降であれば、Orchestrator で
RunDisconnectedHours、HearbeatPeriodSeconds、NuGet フィード、および SignalR の設定を変更するたびに Robot を再起動する必要がなくなりました。
-
トラブルシューティングを行いやすくするため、Orchestrator の PII を表示できるようにしました。PII を表示するには
UiPath.Orchestrator.dll.config(以前のweb.config) に次のキーを追加します:<add key="ExternalAuth.ShowPII" value="true" />。このキーは既定ではUiPath.Orchestrator.dll.configに表示されず、既定の動作では PII の表示が許可されていません。
Scalability.SignalR.AuthenticationEnabled は無効になりました。
-
OData.BackwardsCompatible.Enabledパラメーターが既定でtrueに設定されるようになりました。つまり、入力データを OData モデルの動的プロパティ (例: QueueItem.SpecificContent) 用に変換する際、Orchestrator は既定で特殊文字を解析・保持するようになり、エンコードやエスケープのメカニズムを使用しなくなりました。以前はOData.BackwardsCompatible.Enabledは既定でfalseに設定されており、API 要求を実行する際に構文"Name@odata.type": "#String"を用いてデータ型を指定しない限り、特殊文字はエンコード/エスケープされていました。
-
お使いのオートメーション プロジェクトが文字のエンコード/エスケープに対処するようにデザインされており、上記以外のメソッド (正規表現のエスケープ解除の式など) を使用している場合は、今後は機能しない可能性があるため、適宜調整してください。または、
OData.BackwardsCompatible.Enabledをfalseに設定して以前の挙動を保持してください。
-
新しいファイルを MinIO バケットにアップロードする際の問題が検出されました。アップロードしたファイルが破損し、機能しなくなります。v20.10.1 より前にアップロードしたファイルは影響を受けません。この問題は v2020.10.3 の Orchestrator で修正されています。
重要: v2020.10.1 または v2020.10.2 の Orchestrator では MinIO ストレージ バケットを使用しないでください。 - v2020.10 からは、Robot ロールにプロセスの表示権限を付与しない限り Studio の [リソース] パネルにプロセスが表示されません。v2020.10 の Orchestrator では不足している権限を追加しましたが、過去のバージョンからアップグレードする場合は権限を明示的に付与するようにしてください。
- アップグレードに失敗してロールバックが実行されるたびに、Administrator ロールのアクションに対する編集権限とアクションの割り当てに対する作成権限が失われます。
- Windows のログイン操作を中断した後、ユーザーが [ログイン] ページにリダイレクトされません。
- カスタムの NLog ターゲットは、アップグレード時に自動的に移行されません。それらは、Identity Server と Webhook サービスに手動で移行する必要があります。Identity Server の NLog ドキュメントをご覧ください。
-
v3 のフィード URL を使用すると、パッケージとライブラリの表示に関する問題が数点発生します。
- v3 の外部フィードを使用すると、パッケージのパブリッシュ日 ([バージョンを表示] > [パッケージ バージョン]) が正しく表示されません。
- MyGet フィードのパッケージの合計数が、実際にフィードにアップロードされたパッケージ数よりも大幅に多く表示されます。
- v2019.4.4 以前の Robot を Orchestrator に接続しようとする際に、Orchestrator でフローティング ロボットが定義されていないと、誤ったエラー メッセージが表示されます。この問題は、マシン テンプレートによって生成されたキーを接続に使用している場合にクラシック フォルダー内でのみ発生します。具体的には、「ロボットが存在しません。」と表示されるべき箇所で、代わりに「サーバー上に利用可能なライセンスがありません。」というメッセージが表示されます。
- ID アプリケーション プールが停止しているか、リサイクルが実行されていると、[ユーザー プロファイル] ページに
"An error has occurred"(エラーが発生しました) というメッセージが表示されます。 +記号を含むパッケージ バージョンはプロセスの作成に使用できないため、Orchestrator 内では使用できません。- 特定のウイルス対策プログラムを使用していると Identity Server 移行ツールに干渉し、既定の Windows 一時ディレクトリでの実行可能ファイルの実行がブロックされる場合があります。これを回避するには 'tmpDirectory' パラメーターを指定してください。
- Studio 内の Orchestrator フィードの言語設定が Robot の言語設定を無視し、Robot の言語に関係なくフィードが英語で表示されます。
- Active Directory で無効化されているユーザーが Orchestrator で除外されません。このため、無効な AD ユーザーを Orchestrator に追加できてしまいます。
- v2020.4 の Orchestrator ではローカル ユーザーのメール アドレスを編集できませんでした。今回のリリースではこのオプションを再び追加しました。
- 以前は、非運用環境で [ジョブを開始] アクティビティを使用してジョブを開始する場合、実行に使用できるのは Unattended ランタイムのみで、利用可能な Unattended ランタイムがない場合はジョブは保留中ステートになっていました。今後は、利用できる Unattended ランタイムがない場合は NonProduction ランタイムが消費されます。
- Chrome 内で Windows 認証を試みると、「
An unexpected error occurred (500). The chunked cookie is incomplete.(予期せぬエラーが発生しました (500)。チャンク Cookie が不完全です。)」というエラー メッセージが表示されていました。この問題は、ブラウザーの Cookie のサイズ制限を超過したことに起因するものであり、複数の AD グループに属するユーザーに対して発生していました。 - 資格情報ストアの作成または更新が不適切である場合に発生するエラー メッセージが [アラート] ページに表示されず、設定ミスの詳細を確認できませんでした。
- テスト実行のジョブを強制終了すると、Orchestrator のジョブのステートが不適切なものになっていました。
- ユーザー エクスペリエンスの一貫性を向上させるため、テスト スケジュールの [削除]、[有効化]、[無効化] ボタンの表示順を変更しました。
- Folder Administrator ロールを持つユーザーが前提条件を満たしていても、手動で権限を付与されない限りはテスト機能にアクセスできませんでした。
- Test Automation を無効化しても、実行中のテスト スケジュールが無効化されませんでした。
- Azure のデプロイで、ユーザーが空の [ID 管理] の [ハブ] ページにリダイレクトされることがありました。Azure のデプロイ スクリプト用に
-orchestratorUrlパラメーターを追加して、この問題を修正しました。 - ログアウトしようとすると、代わりに Orchestrator のホームページにリダイレクトされていました。
- アップグレード中に NuGet パッケージ ストレージの
compositeに移動すると、パッケージが正しい場所に移行されませんでした。 - Orchestrator インストーラ―が証明書の代替サブジェクト名を適切に検証していませんでした。
- ごくまれに、同一のジョブが複数のマシンで同時にトリガーされていました。この問題は、同一のマシン テンプレートを使用して Orchestrator に接続されたマシンで発生していました。
- 以前は 32 文字を超える名前のユーザー グループは編集できませんでした。今回、グループ名 ([グループまたはユーザー名] フィールド) の文字数制限を 256 文字に増やしました。
