Диагностика запуска Unattended-Робота через Координатор на Windows#

Если Работа создана, но Unattended-Робот не выходит на связь или запускается с задержкой, необходимо определить этап, на котором остановился запуск. Инструкция предназначена для администратора Windows и относится к запуску через Координатор.

Для проверки требуются доступ к машине Координатора, логам и учетной записи Windows, выделенной для Робота. Если доступа нет, необходимо передать проверку администратору этих машин. Пароль учетной записи не следует включать в переписку и диагностические материалы.

Определение этапа запуска#

Координатор создает и удерживает подключение к удаленному рабочему столу по протоколу RDP. В пользовательском сеансе Windows запускается Робот, который получает Работу из Оркестратора.

Запуск проходит следующие этапы:

1. В Оркестраторе создается Работа для Unattended-Робота.
2. Координатор получает команду на открытие пользовательского сеанса.
3. RDP-клиент подключается к машине Робота и выполняет вход в Windows под учетной записью Робота.
4. В сеансе запускается Робот и устанавливает связь с Оркестратором.
5. Робот получает и выполняет Работу.

Доступность Координатора подтверждает только его связь с Оркестратором. Она не подтверждает успешный вход в Windows или запуск Робота.

Для локализации задержки необходимо сопоставить время создания Работы, попытки RDP-подключения в логе Координатора и запуска Робота в его локальном логе. Если запись о попытке подключения отсутствует, сначала проверить назначение Координатора и наличие команды на запуск. Если подключение создается, но Робот не появляется в сети, перейти к проверке RDP-подключения.

Проверка логов Координатора и Робота#

Логи необходимо сохранить до переустановки, перезапуска служб или завершения сеанса. Для анализа требуется интервал, который включает создание Работы, неудачную попытку и последующий успешный запуск, если он был.

Типичные расположения логов:

• Координатор — C:\ProgramData\Sherpa RPA Coordinator\Log\SherpaRPAService.log на машине Координатора.
• Робот — %APPDATA%\Sherpa RPA Data\Log в учетной записи Windows, выделенной для Робота. В этой папке необходимо выбрать записи за дату и время сбоя.

Переменная %APPDATA% относится к текущей учетной записи Windows. Если администратор вошел под своей учетной записью, этот путь откроет его профиль, а не профиль Робота.

Для неудачной попытки в логе Координатора необходимо найти адрес машины и логин, с которыми выполнялось подключение. Если присутствуют поля MachineIP, MachineLogin и WindowTitle, они помогают сопоставить записи одной попытки. Значение MachineIP может содержать имя машины. Значение WindowTitle не заменяет адрес и логин для входа.

Лог Робота показывает, запустилось ли приложение в пользовательском сеансе и какие ошибки возникли после запуска. Если за нужный интервал новых записей нет, необходимо проверить сам вход в Windows и автоматический запуск Робота.

Если Робот запустился, в его логе необходимо проверить режим запуска и ошибки Лицензии. При отсутствии Лицензии Робот может некоторое время ожидать, а затем выйти из сеанса. Это не означает, что требуется переустановка Координатора.

Проверка RDP-подключения#

Проверку необходимо выполнять с машины Координатора. Администратор входит на эту машину под своей учетной записью, а подключение к целевой машине создает с логином Робота из лога. Успешный вход с другого компьютера или под другой учетной записью не воспроизводит условия неудачной попытки.

Для ручной проверки подключения администратору необходимо выполнить следующие действия:

1. Сохранить адрес машины и логин из лога конкретной попытки. Сверить их с данными Unattended-Робота в Оркестраторе. Если учетные данные поступают из Ресурса, проверить выбранный Ресурс.

2. С машины Координатора запустить RDP-клиент. Для стандартного клиента Windows используется команда mstsc. На скриншоте показано окно после запуска клиента.

   

   Для отображения параметров подключения необходимо нажать на кнопку "Показать параметры". На скриншоте показана вкладка "Общие" перед вводом данных подключения.

   

3. Подключиться к тому же адресу под той же учетной записью, которые указаны в логе неудачной попытки. Пароль необходимо получить по принятому в организации защищенному каналу.

4. Дождаться завершения входа в Windows. Зафиксировать точный текст ошибки, запрос дополнительного подтверждения, отсутствие рабочего стола или длительность входа.

5. Если рабочий стол открылся, проверить автоматический запуск Робота и появление новых записей в его локальном логе.

6. Сопоставить время этих событий с исходной попыткой Координатора.

Координатор поддерживает FreeRDP и стандартный RDP-клиент Microsoft. Для диагностики необходимо записать, какой способ выбран в установленном Координаторе. Проверка через mstsc подтверждает результат для клиента Microsoft и сама по себе не подтверждает работу FreeRDP.

Проверку следует согласовать с администратором машины. Подключение к учетной записи, в которой уже выполняется Работа, может повлиять на ее сеанс. Не следует завершать действующие сеансы и повторно запускать Работу без проверки ее текущего состояния.

Разбор результата подключения#

Дальнейшая проверка зависит от того, что произошло при ручном входе:

• Подключение не установлено — зафиксировать ошибку RDP и передать администратору проверку доступности машины, сетевого подключения и разрешения удаленного входа.
• Windows не принимает учетные данные — проверить адрес, домен, логин и пароль, которые используются для Робота. Вход администратора под своей учетной записью не подтверждает работоспособность учетной записи Робота.
• Вход требует дополнительного действия или долго не завершается — сохранить сообщение или скриншот и передать администратору проверку входа в Windows. Например, сообщение, заданное групповой политикой, может ожидать подтверждения до открытия рабочего стола. Робот еще не запущен и не может подтвердить это сообщение. Ручное подтверждение не следует считать успешной проверкой автоматического запуска. Изменение политики необходимо согласовать с администратором.
• Рабочий стол открылся, но Робот не запустился — проверить установку Робота для этой учетной записи и режим Unattended. В Планировщике задач Windows проверить задание, созданное при установке для запуска Робота при входе в учетную запись. Режим Attended вместо Unattended необходимо учитывать при поиске причины. Для установки без Дизайнера используется Sherpa RPA Runtime.
• Робот запустился, но не установил связь с Оркестратором — изучить его локальный лог и проверить настройки подключения Робота к Оркестратору.
• Робот в сети, но Работа не выполняется — проверить назначение и состояние Работы и сообщения Робота. Наличие RDP-подключения не подтверждает получение Работы.

После устранения найденной причины необходимо повторить запуск через Координатор. Результат проверки — Робот автоматически выходит на связь и получает ожидающую Работу. Успешный ручной вход без повторной проверки автоматического запуска недостаточен.

Сообщение о сбросе зависшей сессии#

Разбор сообщения помогает отличить срабатывание порога сброса от причины задержки запуска Робота.

В сообщениях Координатора может появиться следующий текст:

The suspended session was reset. Preset reset time: 10 minutes.

Сообщение указывает на срабатывание настроенного сброса зависшей сессии. Значение 10 minutes в этой записи относится к указанному порогу сброса. Оно не устанавливает нормальную длительность запуска Работы и не доказывает неисправность службы Координатора.

В Координаторе 1.33 порог сравнивается с давностью последнего сообщения Робота в Оркестратор, а не со временем создания Работы. В этой версии сброс закрывает RDP-клиент. Состояние пользовательского сеанса Windows и приложений на целевой машине необходимо проверять отдельно.

Настройка "Сбрасывать зависшие сессии через:" описана в инструкции по установке Координатора на Windows. Сброс предназначен в том числе для ситуации, когда Робот завершил Работу и инициировал выход, но Windows не завершила сеанс, например из-за обновлений или другого приложения.

При повторении сообщения необходимо сохранить предшествующие записи Координатора и лог Робота, затем воспроизвести вход по данным неудачной попытки. Изменение порога сброса и переустановка Координатора не заменяют поиск причины, по которой сеанс или Робот не запустились штатно.

Подготовка данных для технической поддержки#

Если причина не установлена, необходимо передать в техническую поддержку результаты проверки:

• версии Координатора, Робота и Оркестратора, версию Windows и выбранный RDP-клиент.
• время создания Работы, неудачной попытки, сообщения о сбросе и последующего запуска с указанием часового пояса.
• логи Координатора и Робота за этот интервал. Если новых записей Робота нет, указать это отдельно.
• результат ручного входа с машины Координатора с теми же адресом и логином, включая точный текст ошибки и длительность ожидания.
• сведения о том, появился ли рабочий стол, запустился ли Робот автоматически и установил ли связь с Оркестратором.
• результат повторного запуска через Координатор после выполненных исправлений.

Материалы необходимо передавать по защищенному каналу организации. Пароли и ключи не включаются в отчет. Перед передачей логов и скриншотов требуется проверить, не содержат ли они секретов и данных других Пользователей.

Дополнительные сведения о расположении и настройке логов приведены в статье "Внешний мониторинг и логирование".