How to resolve when the automation works in Robot's Attended Mode but when Not Unattended Mode ?
Issue Overview : When an automation is run in Attended mode (i.e. with a human user is logged in and watch the Robot) it works. But when it is run in Unattended mode, it fails.
Other symptoms can be that the Robot is clicking in the wrong location, that a random window was opened, items from the task bar are opened or that the application is in an unexpected state.
Scenario Description: Automation works in attended mode but not unattended mode.
- Robot is clicking the wrong location.
- When an automation is run in Attended mode (i.e. with a human user is logged in and watch the Robot) it works.
- But when it is run in Unattended mode, it fails.
Other symptoms can be that the Robot is clicking in the wrong location, that a random window was opened, items from the task bar are opened or that the application is in an unexpected state.
Root Cause : The only difference between an Attended Robot and an Unattended robot is in how the windows session gets created. In the scenario involving an Attended Robot, a human user initializes the window session and in the scenario with an Unattended bot the Robot service initializes the window session.
Typically, when this issue is encountered the human user is initializing the session through an RDP connection. In this case the RDP connection will initialize a Windows session like their local computer’s environment. By default, the resolution and scaling between the remote session and their local session will be identical.
On the other hand, the Robot Service either relies on system settings or whatever is specified in the Robot settings. Additionally, it always sets the scaling to 100%. (The scaling can still be adjusted, but it must be done by configuring the computer to override the scaling for any remote connection.)
For a more detailed explanation on how the Robot Service creates a session see here .
Diagnosing the Issue:
1. IMPORTANT: When testing make sure that the Robot user has been logged out of the Robot machine. The Robot Service can create a windows session for the Robot.
2. If the issue is that the Robot works in Attended Mode and Unattended mode, the problem is almost guaranteed to be related to resolution. That should be the only difference between an attended and unattended bot. As such, first go to the section title “Fixing Resolution Problems”. Also, read the section titled “Best Practices in Relation to Resolution”
3. If fixing the resolution problems does not help, the next thing to do is to check the scaling settings of the windows session when the automation runs in attended mode.
a. Login to the machine as if an Attended Automation were about to be executed.
b. Open a powershell window (Just open a Run dialog box and type “powershell”)
c. Execute the following command
(Get-ItemProperty 'HKCU:\Control Panel\Desktop\WindowMetrics' -Name AppliedDPI).AppliedDPI
d. If the returned value should be 96. If it is not, that means that the Robot was developed in an environment that did not have scaling set to 100%. See the section forcing “Forcing Scaling”
4. If none of the above steps help, the next thing to do is catch the problem in action. This can be difficult because it must be done without logging into the Robot Machine.
a. Try using the Robot Streaming tool, found here
b. Also try using the recording feature of Orchestrator found here
5. If none of the above steps help in identify the issue, please open a support ticket with UiPath.
Best Practices in Relation to Resolution:
1. Ensure to review the Ui Automation following here
2. Factor in Resolution in the design process. There are many cases, in which developers do not realize a certain activity depends on the resolution. As a best practice, make it a design requirement that the development environment has the same resolution and scaling as the production environment.
3. Additionally, if resolution is not specified, system defaults will be specified. This could result in very low resolutions that the application was not designed to run in. UiElements might be offscreen, there could be visual distortions, etc.
4. Activities that can depend on resolution:
a. Image based activities (i.e. Find Image, OCR, etc)
b. UiAutomation Activities with clipping regions enabled
c. UiAutomation Activities “WaitVisible” enabled
d. Click Activities that do not use “SendWindowMessages” or “SimulateClick”
- If configured this way, the activity will throw an error if the element is off screen
- If the CursorPosition property is configured, see the section “Robot Clicking the Wrong Location”
Robot Clicking the Wrong Location -
1. If the Robot is clicking in the wrong position, that usually means that the CursorPosition activity was configured on the activity.
2. This property can sometimes be configured unintentionally when using the Recording feature in Studio. In 99% of automations, it is not necessary to configure this property.
3. Check the activity where the click happens in the wrong location. If it has the CursorPosition properties configured, determine if this was intentional. Most likely these properties need to be removed.
Fixing Resolution Problems -
1. Logon to the Robot machine as if an attended automation were about to be executed (i.e. An automation that will run successfully).
2. Open a powershell window (Just open a Run dialog box and type “powershell”)
3. Execute the following commands
a. [void][Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
[System.Windows.Forms.SystemInformation]::PrimaryMonitorSize
b. Make a note of the Width and Height values that are returned.
4. For font smoothing do the following:
a. Go to the start menu and type “View advanced system settings”
b. On the Advanced tab, select “Settings” under performance.
c. See if “Smoooth edges of screen fonts” is checked.
5. If Bit Depth or Font smoothing is needed, on the local machine that connects to the Robot machine, check the display settings.
a. Right click the Desktop and select “Display Settings”
b. Go to “Advanced display settings” This will contain the bit depth settings.
6. Logon to Orchestrator
7. Go to the Robot section of Orchestrator where modifications can be made.
8. Go to the Robot that is executing the problematic automation and go to its settings. See here
9. In the settings window, change the Robot to use RDP sessions when running in unattended mode. Also specify the resolution.
a. For detailed instructions see here
b. Login To Console needs to be enabled and set to No.
c. Resolution Width and Height needs to be specified.
d. Resolution depth is almost always 32bit.
e. Bit Depth and Font smoothing are less important. They are usually only needed for image-based automation.
Forcing Scaling -
1. In this scenario, the best solution is to rework the automation in a development environment that uses scaling that is set to 100%. The following solution is meant as a temporary work around.
2. Scaling can be a problem in two scenarios:
a. In rare circumstances, the selector will change with scaling
b. Due to scaling the Robot will click in the wrong location. See the section “Robot Clicking the Wrong Location”
3. The following changes need to be made in the registry. This will force the computer to ignore the Robot scaling setting of 100%. Additionally, the Robot needs to be running in an RDP session. See here
a. The registry key that is used to specify the resolution.
- Registry Key Location: HKEY_CURRENT_USER\Control Panel\Desktop\LogPixels
- Registry Key (32Bit Dword): LogPixels
If LogPixels does not exist then create it. Assign it a Decimal Value. For a list of the possible values see here
|
DPI |
Scale factor |
|
96 |
100 |
|
120 |
125 |
|
144 |
150 |
|
192 |
200 |
b. The registry key that tells the remote connection to ignore the robot scaling
Registry Key Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\
Registry Key (32Bit Dword): IgnoreClientDesktopScaleFactor
Turn on = 1
Turn off = 0