Date de publication : 15 décembre 2020
Nouveautés
Intégration CyberArk CCP
Plusieurs bonnes nouvelles sont à venir, étant donné que nous avons élargi et amélioré nos fonctionnalités de magasin d’identifiants en intégrant CyberArk CCP à Orchestrator
Vue d'ensemble (Overview)
Le fournisseur d’identifiants central (CCP) est la méthode AAM sans agent utilisée pour intégrer Orchestrator à CyberArk. Il permet la récupération d’informations sensibles telles que les informations d’identification du robot et les actifs d’identifiants de CyberArk sans déployer d’agent sur le serveur, car les mots de passe stockés dans un coffre sont récupérés dans le fournisseur d’identifiants central, où ils peuvent être consultés par des applications distantes autorisées. Un certificat client est nécessaire pour assurer la récupération sécurisée des informations d’identification.
Pour réussir l’intégration à CyberArk® CCP, nous vous suggérons de jeter un œil à la façon de configurer correctement votre environnement dans CyberArk® PVWA :
- Create an application for your Orchestrator instance and add client certificates.
- Créer un coffre-fort et y ajouter des membres pour garantir les autorisations appropriées.
Lors de la mise à niveau vers v2020.10.4, CyberArk CCP est activé automatiquement si CyberArk est activé dans votre instance avant la mise à niveau. Si ce n’est pas votre cas, ajoutez UiPath.Orchestrator.SecureStore.CyberArkCCP.dll au paramètre Plugins.SecureStores dans UiPath.Orchestrator.dll.config pour l’activer.
Améliorations
Stratégies de comptage des tâches
Dans cette version, nous vous donnons le plein contrôle sur la stratégie de comptage des tâches lancées par le biais de déclencheurs. Le paramètre Triggers.JobsCountStrategy vous permet de choisir la stratégie qui convient le mieux à vos besoins comme suit :
PerProcess- Un déclencheur lance le nombre de tâches requises en tenant compte de toutes les tâches en attente pour le processus spécifié. Par exemple, deux déclencheurs définis pour le même processus lancent respectivement 3 et 5 tâches. Si le premier déclencheur lance 3 tâches à un moment donné, lorsque le second déclencheur est déclenché, 2 tâches sont lancées de manière à atteindre les 5 tâches requises.PerTrigger- Un déclencheur lance le nombre requis de tâches en tenant compte des tâches existantes précédemment lancées par ce même déclencheur. Par exemple, un déclencheur est défini pour lancer 9 tâches à un moment donné. Si 2 tâches ont été complétées avec succès au moment où ce déclencheur est à nouveau déclenché, Orchestrator lance 2 autres tâches afin d’atteindre les 9 tâches requises.NoLimit- Le déclencheur lance le nombre de tâches requises sans tenir compte des tâches existantes en attente. Par exemple, un déclencheur est défini pour lancer 5 tâches à un moment donné. La deuxième fois que le déclencheur est déclenché, 5 autres tâches sont lancées.
Learn about the Triggers.JobsCountStrategy parameter.
Prise en charge des activités de persistance
Dans cette version, nous avons ajouté une prise en charge des activités de persistance dans les workflows basés sur les éléments de la file d’attente. Auparavant, Orchestrator abandonnait les éléments de la file d’attente en cours depuis plus de 24 heures, interférant ainsi avec les workflows de longue durée qui dépassaient la limite des 24 heures. Cette limitation a été supprimée, ce qui vous permet d’avoir une intervention humaine en ce qui concerne vos transactions sans être pressé par le temps.
Cette fonctionnalité n’a pas été fournie dans la version 2020.10.4, comme indiqué dans les notes de publication, en raison d’un incident de notre côté. Notre priorité est de l’ajouter au correctif Orchestrator suivant. La limite de 24 heures pour les éléments de la file d’attente en cours continue d’exister jusqu’à ce que notre équipe l’inclue dans la prochaine version.
Configuration
- Nous vous recommandons maintenant d’utiliser le mode passif pour les installations de nœuds secondaires. Vous pouvez spécifier le paramètre
/passivepour activer une interface utilisateur limitée avec une barre de progression et des fenêtres contextuelles d’erreurs. Alors que seul le mode silencieux était auparavant disponible, vous devriez maintenant utiliser/Quniquement pour les installations non assistées.
Autres
- You can now control whether or not login error codes are displayed in the UI, by using the HideErrorCodesInUi parameter in the Identity Server
appsettings.Production.jsonfile. - La fonctionnalité d’Orchestrator peut être altérée si l’élément
<system.webServer>deweb.configcontient des sections verrouillées. C’est pourquoi nous avons ajouté une vérification supplémentaire dans l’outil de configuration de Platform qui vérifie si l’élément entier<system.webServer>contient des sections verrouillées. Si de telles sections existent, vous devez les déverrouiller manuellement dans IIS. - Pour éviter toute confusion sur ce que le bouton bascule Processus toujours en cours d’exécution (Always Running Processes) fait, nous l’avons renommé Impossible d’arrêter le processus depuis l’assistant UiPath (Process can’t be stopped from UiPath Assistant). Cela signifie que si vous activez cette fonctionnalité à partir de la page des paramètres Processus (Processes), vous ne serez pas en mesure d’arrêter le processus correspondant à partir de l’assistant UiPath.
Résolution de bogues
- All logs generated prior to 2019.10 were displayed on the Logs page without being filtered by the containing folder (formerly organization unit). We added and enabled by default a new
UiPath.Orchestrator.dll.configsetting (Logs.Elasticsearch.EnableFolderIdFilter) which prevents logs that cannot be filtered from being displayed on the Logs page. You can still see such logs by navigating to Logs from the Robots (classic folders) and Jobs pages (More Actions > View Logs). - Chaque fois qu’une mise à niveau échouait et qu’une restauration était exécutée, le rôle Administrateur (Administrator) perdait les autorisations Modifier (Edit) sur les actions et les autorisations Créer (Create) sur l’Affectation de l’action. Le rôle conserve maintenant les deux, même en cas d’échec de la mise à niveau.
- En raison du déplacement de
appSettingsdeWeb.ConfigversUiPath.Orchestrator.dll.config, le scriptConfigure-PlatformNode.ps1provoquait l’échec des migrations d’un seul à plusieurs nœuds. Le script ne génère plus d’erreur. - La migration des paquets ne nettoyait pas le dossier
Storageimporté mais inutilisé suite à une mise à niveau ratée. Le contenu restant est maintenant supprimé. - Le programme d’installation
UiPathOrchestrator.msine vérifiait pas l’espace disque disponible avant le début de la mise à niveau, ce qui pouvait provoquer l’échec de la migration du paquet. Maintenant, un avertissement est émis avant le début de la migration. UiPathPlatformInstaller.exene validait pas les certificats SSL avec des formats d’objets spécifiques, ce qui entraînait soit une défaillance de l’installation, soit un avertissement de mise à niveau.- L’utilisation de l’authentification Windows lors d’une mise à niveau empêchait le programme d’installation
UiPathOrchestrator.mside valider les informations d’identification. Cela entraînait l’échec du processus de mise à niveau. - Le type d’argument n’était pas validé dans Orchestrator, ce qui permettait aux utilisateurs de définir des valeurs de paramètres inappropriées pour leurs processus. La validation est maintenant correctement effectuée et une erreur est générée si l’entrée ne correspond pas au type d’argument défini au moment de la conception.
- La suppression d’un dossier classique ne supprimait pas les utilisateurs associés. Les utilisateurs sont maintenant supprimés lors de la suppression d’un dossier classique.
- La mise à niveau de la version v2020.4 à v2020.10 d’Orchestrator n’attribuait pas les utilisateurs d’Active Directory à partir de dossiers modernes basés sur le modèle d’autorisation Hériter du locataire (Inherit from Tenant). Cela se produisait en dépit d’avoir le groupe parent Active Directory affecté au dossier.
- La suppression des informations d’identification des actifs résidant dans les magasins d’identifiants en lecture/écriture ne les supprimait que dans Orchestrator. Désormais, la suppression des informations d’identification d’un actif dans Orchestrator supprime également l’objet des informations d’identification associé référencé dans le magasin d’identifiants. Veuillez vous assurer que les informations d’identification des actifs à supprimer ne sont pas utilisées dans d’autres endroits tels que les projets d’automatisation.
- Les sessions utilisateur n’expiraient pas après la fin du délai d’inactivité, empêchant les utilisateurs d’être déconnectés de leur session comme prévu.