Windows-Sitzungen

UiPath Robot führt Prozesse in einer interaktiven Windows-Sitzung aus. Es gibt zwei Arten von Windows-Sitzungen, die der Roboter starten kann:

• Konsolensitzung
• FreeRDP-Sitzung

Der Typ der Sitzung, die der Roboter startet, wird durch die Option LoginToConsole bestimmt. Standardmäßig ist diese Option aktiviert.

Alle Robotertypen können unabhängig von der Lizenz oder Bereitstellung eine Verbindung zu beiden Arten von Sitzungen herstellen. Bitte beachten Sie, dass High-Density-Roboter nur eine Verbindung zu einer FreeRDP-Sitzung herstellen.

Die in Orchestrator konfigurierten Robotereinstellungen überschreiben die in der Datei UiPath.settings konfigurierten Einstellungen.

Eine Windows-Sitzung wird immer auf der Robotermaschine erstellt, unabhängig vom Typ der Sitzung. Mit anderen Worten, eine Sitzung wird von der Robotermaschine auf derselben Maschine und nicht vom Orchestrator auf der Robotermaschine erstellt.

Wenn ein Prozess von Orchestrator gestartet wird, wird eine Windows-Sitzung wie folgt erstellt:

1. Orchestrator sendet eine Nachricht mit den Prozessdetails an den Roboterdienst.
2. Der Roboterdienst erstellt eine interaktive Windows-Sitzung auf der Maschine.
3. Der Roboterdienst startet den Roboter-Executor in dieser Sitzung.
4. Der Roboter-Executor startet die Prozessausführung.

Der Prozess ist für Konsolen- und FreeRDP-Sitzungen identisch.

Wenn Sie nicht mit Orchestrator verbunden sind, kann die Option LoginToConsole nur über die Datei UiPath.settings konfiguriert werden.

Konsolensitzung

Standardmäßig stellt der Roboter eine Verbindung mit einer Konsolensitzung her. Auf einer Maschine kann jeweils nur eine Konsolensitzung aktiv sein. Wenn es zuvor anders eingestellt wurde, können Sie den Roboter mit einer Konsolensitzung verbinden lassen, indem Sie die Option LoginToConsole über eine der folgenden Methoden aktivieren:

• In der Datei UiPath.settings setzen Sie den Parameter LoginToConsole auf true.
• Wenn Sie einen Roboter in Orchestrator erstellen oder aktualisieren, legen Sie den Wert LoginToConsole auf der Registerkarte Einstellungen auf Yes fest. Standardmäßig ist die Option LoginToConsole deaktiviert. Dies bedeutet, dass die Konfiguration aus der UiPath.settings-Datei verwendet wird. Um den gewünschten Wert von Orchestrator festzulegen, müssen Sie zuerst die Option LoginToConsole
  
  

  

  
  
  Hinweis: Es wird empfohlen, diesen Verbindungstyp für Prozesse zu verwenden, für die keine benutzerdefinierte Auflösung erforderlich ist.

Es kann jeweils nur eine aktive Konsolensitzung auf einer Maschine geben. Dies bedeutet, dass jeweils nur ein Roboter Prozesse auf dieser Maschine ausführen kann. Wenn die Ausführung abgeschlossen ist, wird die Sitzung getrennt, und ein anderer Roboter kann eine Sitzung starten und Prozesse auf dieser Maschine ausführen.

Wenn beim Starten eines Auftrags von Orchestrator eine aktive RDP-Sitzung vorhanden ist, wird die aktive RDP-Sitzung beendet.

Eine Konsolensitzung verwendet die Auflösung, die durch die Standardeinstellungen der Grafikkarte auf der Maschine angegeben wird. Bei VDIs (z. B. Citrix, Hyper-V, VMware) wird die Auflösung in der Regel vom Hypervisor angegeben, der die VDI verwaltet. Bitte beachten Sie, dass Sie keine benutzerdefinierte Auflösung festlegen können.

FreeRDP-Sitzung

In einer FreeRDP-Sitzung erstellt der Roboter eine virtuelle Remotedesktopsitzung auf der Maschine, auf der er ausgeführt wird. Sie können den Roboter mit einer FreeRDP-Sitzung verbinden lassen, indem Sie die Option LoginToConsole deaktivieren, indem Sie eine der folgenden Methoden verwenden:

• In der Datei UiPath.settings setzen Sie den Parameter LoginToConsole auf false.
• Wenn Sie einen Roboter in Orchestrator erstellen oder aktualisieren, legen Sie den Wert LoginToConsole auf der Registerkarte Einstellungen auf No fest. Standardmäßig ist die Option LoginToConsole deaktiviert. Dies bedeutet, dass die Konfiguration aus der UiPath.settings-Datei verwendet wird. Um den gewünschten Wert von Orchestrator festzulegen, müssen Sie zuerst die Option LoginToConsole
  
  

  

  
  
  Hinweis: High-Density-Roboter erfordern eine Verbindung über eine FreeRDP-Sitzung.

Auf einer Windows-Workstation kann es nur eine aktive FreeRDP-Sitzung geben. Dies bedeutet, dass jeweils nur ein Roboter Prozesse auf dieser Maschine ausführen kann. Wenn die Ausführung abgeschlossen ist, wird die Sitzung getrennt, und ein anderer Roboter kann eine Sitzung starten und Prozesse auf dieser Maschine ausführen.

Auf einem Windows Server kann es jedoch eine aktive FreeRDP-Sitzung für jeden Benutzer der Maschine oder sogar mehrere Sitzungen für denselben Benutzer geben. Dies bedeutet, dass mehrere Roboter gleichzeitig Prozesse auf dieser Maschine ausführen können, jeder für den angegebenen Benutzer. In diesem Szenario können Roboter auch Prozesse für einen Benutzer in mehreren Sitzungen ausführen, dürfen sich jedoch nicht auf Hardwareereignisse (z. B. UIAutomation-Aktivitäten) verlassen.

Wenn ein Auftrag von Orchestrator gestartet wird und eine FreeRDP-Sitzung bereits aktiv ist, wird der Prozess in dieser Sitzung ausgeführt.

Es wird empfohlen, diesen Verbindungstyp zu verwenden, wenn der Automatisierungsprozess eine benutzerdefinierte Auflösung erfordert. Sie können eine benutzerdefinierte Auflösung festlegen, indem Sie die Parameter ResolutionWidth, ResolutionHeight und ResolutionDepth an einem der folgenden Speicherorte ändern:

• In der Datei UiPath.settings.
• Auf der Registerkarte "Einstellungen", wenn Sie einen Roboter in Orchestrator erstellen oder aktualisieren.

Prozessausführung über RDP

Das Hauptkommunikationsmittel zwischen einem Ausführungsbefehl und der tatsächlichen Prozessausführung ist der UiPath-Roboterdienst. Wenn kein Prozess ausgeführt werden muss, steht der UiPath-Roboterdienst im Leerlauf auf der Windows-Maschine bereit und erfordert keine aktive Windows-Sitzung. Dies geschieht, um eine ständige offene Kommunikation mit dem Orchestrator sicherzustellen und einen Prozess sofort starten zu können, wenn ein Befehl empfangen wird. Die Kommunikation erfolgt über HTTPS, genauer gesagt über WebSockets (SignalR).

Hinweis: Wenn Sie Unattended-Aufträge in Umgebungen ausführen, die Richtlinien verwenden, die die Kerberos-Authentifizierung für RDP erzwingen, müssen Sie die Umgebungsvariable UIPATH_DNS_MACHINENAME auf der Maschine mit dem Wert True festlegen. Dadurch wird die Verwendung des DNS-Hostnamens für localhost beim Erstellen von RDP-Sitzungen aktiviert.

Bitte beachten Sie, dass die Windows-Sitzung nur dann über RDP erzeugt wird, wenn der Wert der LoginToConsole-Eigenschaft false ist.

Hinweis: Wenn Sie Roboter in einer Umgebung verwenden, die TCP erzwingt, sind Robotersitzungen mit RDP-Verbindungen nicht betroffen.

Wenn ein Startprozessbefehl an den Roboterdienst gesendet wird, erstellt er eine Windows-Sitzung auf dieser Maschine über RDP für den Benutzer des Roboters. Danach erzeugt der Roboterdienst einen Roboter-Executor innerhalb der neu erstellten Sitzung. Der Executor und der Dienst kommunizieren dann über Named Pipes, und der Executor weiß genau, was ausgeführt werden soll. Der Prozess wird dann innerhalb der Windows-Sitzung ausgeführt.

Hinweis: Der Roboter verwendet RDP nur, um eine Windows-Sitzung zu starten. Es wird weder zum Herstellen einer Verbindung von Orchestrator mit der Maschine, auf der der Prozess ausgeführt wird, noch zur Kommunikation mit anderen Komponenten außerhalb der Maschine verwendet.

Architekturüberblick

Wenn ein Auftrag von Orchestrator gestartet wird, stellt der Roboter basierend auf Ihrer Sitzungsverbindungskonfiguration eine Verbindung mit der WinSta0 Windows-Sitzung her. Eine WinSta0-Sitzung (interaktive Sitzung) kann jeweils nur einen aktiven Desktop haben.

Ein Prozess ist mit dem interaktiven Desktop verknüpft, in dem er gestartet wurde, und kann während der Ausführung nicht auf andere Desktops zugreifen. Ein aktiver Desktop stellt Folgendes sicher:

• Prozesse können Benutzereingaben über Hardware-Ereignisse empfangen
• Prozesse können Benutzereingaben über Software-Ereignisse empfangen
• Die Maschinenanzeige wird gerendert und laufend aktualisiert

Eine getrennte Benutzersitzung kann keinen aktiven Desktop haben. Wenn ein Desktop in einer interaktiven Sitzung nicht aktiv ist, tritt Folgendes auf:

• Prozesse können keine Benutzereingaben über Hardwareereignisse empfangen
• Prozesse können Benutzereingaben über Software-Ereignisse empfangen
• Die Maschinenanzeige wird nicht gerendert