- Primeros pasos
- Instalación y actualización
- Tipos de robot
- Componentes de robot
- Licencia
- Conexión de los robots a Orchestrator
- Procesos y actividades
- Registro
- Situaciones concretas
- Reinicio de componentes de UiPath Robot
- Sesiones de Windows
- Inicio de sesión usando el sistema de credenciales de Thales Luna
- Inicio de sesión utilizando el proveedor de almacenamiento de clave nShield
- Redirección de Robots a través de un servidor proxy
- Ejecución de tareas en una ventana RDP minimizada
- Uso de unidades de red asignadas
- Detención de un proceso
- Botón de deshabilitación de detención
- Carpetas de paquetes y rutas de red personalizadas
- Integración de CrowdStrike
- Robot de virtualización de apps citrix
- Control
- Solución de problemas
- Errores comunes de conexión
- Robot que no responde sobre RDP
- Registros de ejecución duplicados
- Errores de robot encontrados con frecuencia
- Aumento de la duración de la ejecución de proceso
- Exigencia de la verificación de la firma de paquetes
- Mensaje demasiado grande para procesarlo
- Errores al ejecutarse como administrador
- Los paquetes NuGet no son accesibles tras la migración
- Actividades de diálogo de control de acceso de usuario y automatización de IU
- Se requiere .NET durante la instalación
- El ensamblado no se puede cargar desde la red o compartir archivos de Azure
- Las actividades no pueden encontrar .NET Runtime
- Resolución de problemas de integración de CrowdStrike

Guía del usuario de UiPath Robot
Sesiones de Windows
El UiPath Robot ejecuta procesos en una sesión de Windows interactiva. El robot puede iniciar dos tipos de sesiones de Windows:
- Sesión de consola
- Sesión RDP
El tipo de sesión que inicie el robot vendrá determinado por la opción LoginToConsole. Por defecto, esta opción está habilitada.
Todos los tipos de Robot, independientemente de la licencia o la implementación, pueden conectarse a ambos tipos de sesiones. Ten en cuenta que los robots de alta densidad solo se conectan a una sesión RDP.
Los ajustes de robot configurados en Orchestrator anulan los ajustes que estén configurados en el archivo UiPath.settings.
Todas las sesiones de Windows, independientemente del tipo de sesión, se crean siempre en la máquina del robot. En otras palabras, las sesiones se crean desde la máquina de robot a la misma máquina, no desde Orchestrator a la máquina del robot.
Cuando se inicia un proceso desde Orchestrator, se crea una sesión de Windows de la siguiente manera:
- Orchestrator envía un mensaje con los detalles de proceso al servicio de robot.
- El servicio de robot crea una sesión de Windows interactiva en la máquina.
- El servicio de robot inicia el ejecutor de robot en esa sesión.
- El ejecutor de robot inicia la ejecución del proceso.
El proceso es el mismo tanto para sesiones de consola como RDP.
Si no estás conectado a Orchestrator, la opción Iniciar sesión en consola solo puede configurarse desde el archivo UiPath.settings.
Sesión de consola
Por defecto, el robot se conecta a una sesión de consola. Solo una sesión de consola puede estar activa por máquina. Si previamente se estableció otra configuración, el robot se puede conectar a una sesión de consola habilitando la opción LoginToConsole, mediante uno de los siguientes métodos:
- En el archivo
UiPath.settings, establece el parámetroLoginToConsolecomotrue. - Al crear o actualizar un robot en Orchestrator, establece el valor LoginToConsole como
Yesdesde la pestaña de Configuración. Por defecto, la opción LoginToConsole está deshabilitada. Esto significa que se utiliza la configuración del archivoUiPath.settings. Para establecer el valor deseado desde Orchestrator, primero debes habilitar la opción LoginToConsole.Nota:Te recomendamos usar este tipo de conexión para procesos que no requieren una resolución personalizada.
Solo puede haber una sesión de consola activa por máquina. Esto significa que solo un robot puede ejecutar procesos en esa máquina cada vez. Cuando finaliza la ejecución se desconecta la sesión, y otro robot puede iniciar una sesión y ejecutar procesos en esa máquina.
Si hay una sesión RDP activa cuando se inicia un trabajo desde Orchestrator, la sesión RDP activa finalizará.
Una sesión de consola usa la resolución especificada por los ajustes predeterminados de la tarjeta gráfica de la máquina. En sesiones de VDI, como Citrix, Hyper-V o VMware, la resolución la suele especificar el hipervisor que administra la VDI. Ten en cuenta que no puedes establecer una resolución personalizada.
Sesión RDP
En una sesión RDP, el robot crea una sesión de escritorio remoto virtual en la máquina en la que se ejecuta. Puedes hacer que el robot se conecte a una sesión RDP deshabilitando la opción LoginToConsole mediante uno de los siguientes métodos:
- En el archivo
UiPath.settings, establece el parámetroLoginToConsolecomofalse. - Al crear o actualizar un robot en Orchestrator, establece el valor LoginToConsole como
Nodesde la pestaña de Configuración. Por defecto, la opción LoginToConsole está deshabilitada. Esto significa que se utiliza la configuración del archivoUiPath.settings. Para establecer el valor deseado desde Orchestrator, primero debes habilitar la opción LoginToConsole.Nota:Los robots de alta densidad requieren conexión a través de una sesión RDP.
En una sesión Windows Workstation solo puede haber una sesión RDP activa. Esto significa que solo un robot puede ejecutar procesos en esa máquina cada vez. Cuando finaliza la ejecución se desconecta la sesión, y otro robot puede iniciar una sesión y ejecutar procesos en esa máquina.
En Windows Server, por el contrario, puede haber una sesión RDP activa para cada usuario de la máquina, o incluso múltiples sesiones para el mismo usuario. Esto significa que múltiples robots pueden ejecutar procesos simultáneamente en esa máquina, cada uno para su usuario designado. En esta situación, los robots también pueden ejecutar procesos para un usuario en múltiples sesiones, pero no deben fiarse de eventos de hardware (como actividades de UIAutomation).
Si se inicia un trabajo desde Orchestrator y ya hay una sesión RDP activa, el proceso se ejecuta en dicha sesión.
Te recomendamos que uses este tipo de conexión si tu proceso de automatización requiere una resolución personalizada. Para establecer una resolución personalizada, modifica los parámetros ResolutionWidth, ResolutionHeight y ResolutionDepth en una de las siguientes ubicaciones:
- Desde el archivo UiPath.settings .
- Desde la pestaña Configuración al crear o actualizar un robot en Orchestrator.
Ejecución de procesos por RDP
El principal medio de comunicación entre un comando de ejecución y la ejecución real del proceso es el mantenimiento de robot de UiPath. Si no es necesario ejecutar ningún proceso, el mantenimiento de robot de UiPath permanece inactivo en la máquina Windows y no requiere una sesión de Windows activa. Esto se hace para garantizar una comunicación abierta constante con Orchestrator y poder iniciar inmediatamente un proceso si se recibe un comando. La comunicación se realiza a través de HTTPS, más concretamente a través de WebSockets (SignalR).
Al ejecutar trabajos unattended en entornos que usan políticas que imponen la autenticación Kerberos para RDP, debes establecer la variable de entorno UIPATH_DNS_MACHINENAME en la máquina, con el valor True. Esto alterna el uso del nombre de host DNS por localhost cuando se crean sesiones RDP.
Ten en cuenta que la sesión de Windows será generada por RDP solo si el valor de propiedad de LoginToConsole es false.
When using robots in an environment enforcing TCP, robot sessions using RDP connections are not impacted.

Cuando se envía un comando de iniciar proceso al servicio de UiPath Robot, se genera una sesión de Windows en esa máquina mediante RDP para el usuario del robot. Acto seguido, el servicio de robot lanza un ejecutor de robot dentro de la sesión recién creada. El ejecutor y el servicio se comunican a través de canalizaciones con nombre, y el ejecutor sabe exactamente qué ejecutar. Entonces, el proceso se ejecuta dentro de la sesión de Windows.
El robot solo utiliza RDP para iniciar una sesión de Windows. No se utiliza para conectarse desde Orchestrator a la máquina donde se ejecuta el proceso, ni tampoco para comunicarse con otros componentes fuera de la máquina.
Información general sobre la arquitectura
Cuando se inicia un trabajo desde Orchestrator, el robot se conecta a la sesión de Windows WinSta0, según tu configuración de conexión de sesiones. Una sesión WinSta0 (sesión interactiva) solo puede tener un escritorio activo.
Un proceso siempre está asociado al escritorio interactivo donde se inició y no puede acceder otros escritorios durante su ejecución. Un escritorio activo garantiza lo siguiente:
- Los procesos pueden recibir datos del usuario mediante eventos de hardware
- Los procesos pueden recibir datos del usuario mediante eventos de software
- La visualización de la máquina se actualiza de manera continua
Una sesión de usuario desconectada no puede tener un escritorio. Si un escritorio no está activo en una sesión interactiva, sucede lo siguiente:
- Los procesos no pueden recibir datos del usuario mediante eventos de hardware
- Los procesos pueden recibir datos del usuario mediante eventos de software
- La visualización de la máquina se detiene
Resolución de problemas de sesiones de Windows
El mantenimiento de robot de UiPath captura una serie de capturas de pantalla de sesión al configurar tu sesión de Windows y las elimina una vez que la sesión se ha creado correctamente. Si la configuración de la sesión falla, guarda las capturas de pantalla en el directorio %ProgramData%\UiPath\SessionScreenshotspara resoluciones de problemas futuras.