Sessions Windows

Le robot UiPath exécute les processus dans une session Windows interactive. Il existe deux types de sessions Windows que le Robot peut démarrer :

• Session de console
• Session FreeRDP

Le type de session que le Robot démarre est déterminé par l'option LoginToConsole. Par défaut, cette option est activée.

Tous les types de Robots, quel que soit la licence ou le déploiement , peuvent se connecter aux deux types de sessions. Veuillez noter que les Robots haute densité se connectent uniquement à une session FreeRDP.

Remarque : les paramètres du Robot configurés dans Orchestrator remplacent ceux configurés dans le fichier UiPath.settings.

Une session Windows est toujours créée sur la machine Robot, quel que soit le type de session. En d'autres termes, une session est créée à partir de la machine Robot vers la même machine, et non d'Orchestrator vers la machine Robot.

Lorsqu'un processus est démarré à partir d'Orchestrator, une session Windows est créée comme suit :

1. Orchestrator envoie un message avec les détails du processus au service Robot.
2. Le service Robot crée une session Windows interactive sur la machine.
3. Le service Robot démarre l'exécuteur Robot dans cette session.
4. L'exécuteur Robot démarre l'exécution du processus.

Le processus est le même pour les sessions de console et FreeRDP.

Si vous n'êtes pas connecté à Orchestrator, l'option LoginToConsole ne peut être configurée qu'à partir du fichier UiPath.settings.

Session de console

Par défaut, le robot se connecte à une session de console. Une seule session de console peut être active à la fois sur une machine. Si des paramètres différents ont été définis précédemment, vous pouvez demander au Robot de se connecter à une session de console en activant l'option LoginToConsole, via l'une des méthodes ci-dessous :

• Dans le fichier UiPath.settings, configurez le paramètre LoginToConsole sur true.
• Lors de la création ou de la mise à jour d'un Robot dans Orchestrator, définissez la valeur LoginToConsole sur Yes dans l'onglet Paramètres (Settings). Par défaut, l'option LoginToConsole est désactivée. Cela signifie que la configuration du fichier UiPath.settings est utilisée. Pour définir la valeur souhaitée à partir d'Orchestrator, vous devez d'abord activer l'option LoginToConsole .
  
  

  

  
  
  Remarque : il est recommandé d'utiliser ce type de connexion pour les processus qui ne nécessitent pas de résolution personnalisée.

Il ne peut y avoir qu'une seule session de console active à la fois sur une machine. Cela signifie qu'un seul Robot peut exécuter des processus sur cette machine à la fois. Une fois l'exécution terminée, la session est déconnectée et un autre Robot peut démarrer une session et exécuter des processus sur cette machine.

S'il existe une session RDP active lorsqu'une tâche est démarrée à partir d'Orchestrator, la session RDP active est interrompue.

Une session de console utilise la résolution spécifiée par les paramètres par défaut de la carte graphique de la machine. Avec les VDI (tels que Citrix, Hyper-V, VMware), la résolution est généralement spécifiée par l'hyperviseur qui gère le VDI. Veuillez noter que vous ne pouvez pas définir de résolution personnalisée.

Session FreeRDP

Dans une session FreeRDP, le Robot crée une session Bureau à distance virtuelle sur la machine qu'il exécute. Vous pouvez demander au Robot de se connecter à une session FreeRDP en désactivant l'option LoginToConsole, via l'une des méthodes ci-dessous :

• Dans le fichier UiPath.settings, configurez le paramètre LoginToConsole sur false.
• Lors de la création ou de la mise à jour d'un Robot dans Orchestrator, définissez la valeur LoginToConsole sur No dans l'onglet Paramètres (Settings). Par défaut, l'option LoginToConsole est désactivée. Cela signifie que la configuration du fichier UiPath.settings est utilisée. Pour définir la valeur souhaitée à partir d'Orchestrator, vous devez d'abord activer l'option LoginToConsole .
  
  

  

  
  
  Remarque : Les Robots haute densité nécessitent une connexion via une session FreeRDP.

Sur un poste de travail Windows, il ne peut y avoir qu'une seule session FreeRDP active. Cela signifie qu'un seul Robot peut exécuter des processus sur cette machine à la fois. Une fois l'exécution terminée, la session est déconnectée et un autre Robot peut démarrer une session et exécuter des processus sur cette machine.

Sur un serveur Windows, cependant, il peut y avoir une session FreeRDP active pour chaque utilisateur de la machine, ou même plusieurs sessions pour le même utilisateur. Cela signifie que plusieurs Robots peuvent exécuter simultanément des processus sur cette machine, chacun pour son utilisateur désigné. Dans ce scénario, les Robots peuvent également exécuter des processus pour un utilisateur sur plusieurs sessions, mais ils ne doivent pas s'appuyer sur des événements matériels (tels que les activités UIAutomation).

Si une tâche est démarrée à partir d'Orchestrator et qu'une session FreeRDP est déjà active, le processus est exécuté dans cette session.

Il est recommandé d'utiliser ce type de connexion si votre processus d'automatisation nécessite une résolution personnalisée. Vous pouvez définir une résolution personnalisée en modifiant les paramètres ResolutionWidth, ResolutionHeight et ResolutionDepth dans l'un des emplacements suivants :

• À partir du fichier UiPath.settings.
• Dans l'onglet Paramètres lorsque vous créez ou mettez à jour un Robot dans Orchestrator.

Exécution du processus sur RDP

Le service de robot est le principal moyen de communication entre une commande d'exécution et l'exécution réelle du processus. Si aucun processus n'a besoin d'être exécuté, le service de robot restera inactif sur la machine Windows et ne nécessitera pas de session Windows active. Cela permet d'assurer une communication ouverte constante avec Orchestrator et de pouvoir démarrer immédiatement un processus lorsqu'une commande est reçue. La communication se fait via HTTPS, plus précisément via WebSockets (SignalR).

Remarque : lors de l'exécution de tâches Unattended dans des environnements utilisant des stratégies qui appliquent l'authentification Kerberos pour RDP, vous devez définir la variable d'environnement UIPATH_DNS_MACHINENAME sur la machine avec la valeur True . Cela permet d'activer/désactiver l'utilisation du nom d'hôte DNS pour localhost lors de la création de sessions RDP.

Veuillez noter que la session Windows n’est démarrée par RDP que si la valeur de la propriété LoginToConsole est false.

Remarque : si vous utilisez des robots dans un environnement appliquant le protocole TCP, les sessions de robot qui utilisent des connexions RDP ne seront pas affectées.

Lorsqu’une commande Démarrer le processus est envoyée au service de robot UiPath, elle crée une session Windows sur cette machine via RDP pour l’utilisateur du robot. Après cela, le service de robot UiPath démarre un exécuteur Robot à l’intérieur de la session nouvellement créée. L’exécuteur et le service communiquent ensuite par l’intermédiaire de canaux nommés, et l’exécuteur sait exactement quoi exécuter. Le processus est ensuite exécuté à l’intérieur de la session Windows.

Remarque : le Robot n'utilise RDP que pour démarrer une session Windows. Le robot utilise uniquement RDP pour démarrer une session Windows. Il n’est pas utilisé pour se connecter d’Orchestrator à la machine sur laquelle le processus est exécuté, ni pour la communication avec d’autres composants à l’extérieur de la machine.

Présentation de l'architecture

Lorsqu'une tâche est démarrée à partir d'Orchestrator, le Robot se connecte à la session Windows WinSta0 en fonction de la configuration de votre connexion de session. Une session WinSta0 (session interactive) ne peut comporter qu'un seul bureau actif à la fois.

Un processus est associé au bureau interactif dans lequel il a démarré et ne peut pas accéder à d'autres bureaux pendant l'exécution. Un bureau actif garantit les éléments suivants :

• Les processus peuvent recevoir des saisies de l'utilisateur via des événements matériels
• Les processus peuvent recevoir des saisies de l'utilisateur via des événements logiciels
• L'affichage de la machine est rendu et mis à jour en continu

Une session utilisateur déconnectée ne peut pas avoir de bureau actif. Si un bureau n'est pas actif dans une session interactive, les événements suivants se produisent :

• Les processus ne peuvent pas recevoir de saisie de l'utilisateur via des événements matériels
• Les processus peuvent recevoir des saisies de l'utilisateur via des événements logiciels
• L'affichage de la machine n'est pas rendu