Windows-Sitzungen

Der Roboter führt Automatisierungen in einer Windows-Sitzung aus und startet eine Konsole oder eine RDP-Sitzung basierend auf der LoginToConsole- Einstellung im Orchestrator. Während alle Roboter eine Verbindung mit beiden Sitzungstypen herstellen können, verwenden High-Density-Roboter nur RDP-Sitzungen.

Wie es funktioniert

Eine Windows-Sitzung wird immer auf der physischen oder virtuellen Maschine erstellt, auf der der Roboter installiert ist. Der Orchestrator erstellt keine Windows-Sitzungen direkt. Wenn ein Auftrag im Orchestrator gestartet wird, findet stattdessen die folgende Sequence statt:

1. Der Orchestrator sendet eine Nachricht mit den Details des Prozesses an den UiPath-Roboterdienst auf der Maschine.

2. Der Roboterdienst erstellt eine interaktive Windows-Sitzung auf der Maschine: WinSta0 .

3. Der Roboterdienst startet den Roboter-Executor in der zuvor erstellten Sitzung.

4. Der Roboter-Executor startet dann die Ausführung der Automatisierung in dieser Sitzung.

Der Roboterdienst verbindet den Befehl zur Ausführung einer Automatisierung mit der tatsächlichen Ausführung.

Ohne ausstehende Aufträge wechselt der Roboterdienst in einen inaktiven Status und erfordert keine aktive Windows-Sitzung. Der Status inaktiv ermöglicht die ständige Kommunikation mit dem Orchestrator und gewährleistet so die sofortige Ausführung beim Empfang eines Befehls. Die Kommunikation erfolgt über WebSockets (SignalR).

Konsolensitzung

Dies ist die standardmäßige Ausführungsumgebung.

In einer Konsolensitzung führt der Roboter Aufträge aus, während ein Benutzer auf der Hosting-Maschine angemeldet ist. Dieser Sitzungstyp wird im Allgemeinen empfohlen für:

• Attended-Automatisierungen, da sie die Interaktion mit jeder geöffneten Anwendung ermöglichen und die Aktionen eines menschlichen Benutzers imitieren.

• Automatisierungen ohne benutzerdefinierte Bildschirmauflösung, da Konsolensitzungen die Grafikeinstellungen der Hostingmaschine oder die vom VDI-Hypervisor angegebenen Einstellungen verwenden.

• Ausführen einer Automatisierung nach der anderen, da eine neue Ausführung beginnt, sobald die vorherige beendet ist und der ausführende Roboter die Verbindung zur aktiven Sitzung trennt.

RDP-Sitzung

In einer RDP-Sitzung (Remote Desktop Protocol) führt der Roboter Aufträge aus, wenn sich ein Benutzer remote bei einer Maschine anmeldet. Dieser Sitzungstyp wird im Allgemeinen empfohlen für:

• Unattended-Automatisierungen, da sie die Ausführung von Aufgaben ermöglicht, die keine Benutzerinteraktion erfordern oder wenn die Maschine gesperrt oder der Benutzer abgemeldet ist.

• Automatisierungen, die eine benutzerdefinierte Bildschirmauflösung erfordern, indem Sie die Breite, Höhe und Tiefe der Auflösung auf der Registerkarte „Robotereinstellungen “ im Orchestrator festlegen.

• Windows-Maschinen, um jeweils eine Automatisierung auszuführen, da eine neue Ausführung beginnt, sobald die vorherige beendet ist und der ausführende Roboter die Verbindung zur aktiven Sitzung trennt.

• Windows Server-Maschinen, um mehrere Automatisierungen gleichzeitig auszuführen:

  • für denselben Benutzer in seinen unterschiedlichen RDP-Sitzungen

  • für mehrere Benutzer, jeder in seiner RDP-Sitzung

Die Option LoginToConsole im Orchestrator

Wenn Sie ein Roboterkonto im Orchestrator definieren oder bearbeiten, können Sie den Sitzungstyp auswählen, der von Ihren Robotern zum Ausführen von Automatisierungen verwendet wird. Verwenden Sie dazu die Option Anmelden bei der Konsole .

Auf der Seite Mandant > Zugriff verwalten > Roboterkonten > Robotereinstellungen im Orchestrator ist die Option Bei der Konsole anmelden standardmäßig deaktiviert. Der Roboter führt Aufgaben jedoch standardmäßig in einer Konsolensitzung aus.

Um die Konsolensitzung zu aktivieren, aktivieren Sie die Option Anmelden bei der Konsole und wählen Sie Ja aus. Wenn ein Auftrag während einer aktiven RDP-Sitzung von Orchestrator gestartet wird, wird die RDP-Sitzung automatisch beendet.

Um die RDP-Sitzung zu aktivieren, aktivieren Sie die Option Anmelden bei der Konsole und wählen Sie Nein aus. Wenn ein Auftrag von Orchestrator gestartet wird und eine RDP-Sitzung bereits aktiv ist, führt der Roboter den Auftrag innerhalb der aktiven RDP-Sitzung aus.

Prozessausführung über RDP

Die folgende Abbildung fasst die Prozessausführung über RDP zusammen:

1. Der Roboterdienst erhält den Befehl, eine Ausführung von Orchestrator über das HTTPS-Protokoll namens WebSockets (SignalR) zu starten.

2. Der Roboterdienst erstellt dann mithilfe von RDP eine Windows-Sitzung auf der Maschine. Diese RDP-Sitzung wird für den Benutzer erstellt, der dem Roboter zugewiesen ist.

3. Sobald die RDP-Sitzung erstellt wurde, erzeugt der Roboterdienst einen Roboter-Executor innerhalb dieser Sitzung. Der Roboterdienst und der Roboter-Executor kommunizieren miteinander über Named Pipes. Mit dieser Methode kann der Executor genau wissen, welche Aufgaben ausgeführt werden müssen.

4. Die Aufgaben werden innerhalb der generierten Windows-Sitzung ausgeführt.

Hinweis:

• Der Roboterdienst verwendet RDP ausschließlich, um eine Windows-Sitzung auf der Maschine zu starten, auf der der Roboter installiert ist. RDP wird weder zum Verbinden des Orchestrators mit der Maschine, auf der der Prozess ausgeführt wird, noch zur Kommunikation mit anderen Komponenten außerhalb der Maschine verwendet.

• Um Unattended-Automatisierungen in Umgebungen auszuführen, in denen RDP-Sitzungen eine Kerberos-Authentifizierung erfordern, müssen Sie den DNS-Hostnamen für den localhost-Wert verwenden. Fügen Sie dazu die folgende Umgebungsvariable auf Ihrer Maschine hinzu:

  UIPATH_DNS_MACHINENAME=True

• Das Ausführen von Automatisierungen in Umgebungen, die TCP erzwingen, beeinflusst nicht Ihre RDP-Sitzungen.

Fehlerbehebung bei Windows-Sitzungen

Der Roboterdienst erfasst eine Reihe von Sitzungs-Screenshots beim Einrichten Ihrer Windows-Sitzung und löscht sie, sobald die Sitzung erfolgreich erstellt wurde. Wenn die Sitzungseinrichtung fehlschlägt, werden die Screenshots im Verzeichnis %ProgramData%\UiPath\SessionScreenshots für die zukünftige Fehlerbehebung gespeichert.