A bit long winded with the different test scenarios and screenshots. If you are experiencing other outcomes from the below, would love to hear about your use case and could test it out within my own environment if you’re interested!.
My expectation is if you are running a job that connects to a pre-existing session (Console:false) and disconnecting the local session while the process is still running, this will lock the session, this is a security feature of Windows/RDP. I’m not familiar enough, but maybe having a RDS/Terminal server could configure it differently(?)
If you want the process to run its course normally, your options are to keep the RDP session open until the Job is complete or return the session to the console. The later is a security risk as anyone that can access the console physically or virtually will be able to access an unlocked session until the session is secured again by locking it or logging off (which the UiRobot service should do when the job is complete).
That’s correct, my usage of “Interactive Session” is referring to a RDP session that is not logging into the host’s console by setting the
Login to Console:False. When thinking of policies that is referring to the Windows Host’s Group Policies, couple examples.
Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections
Restrict Remote Desktop Services users to a single Remote Desktop Services Session
Limit number of connections
Computer Configuration\Windows Settings\Security Settings\Local Policy\User Rights Assignment
Allow log on through Remote Desktop Services
I’m testing this on cloud.uipath.com (20.2.21-release.31) with a Windows 2016 host machine running the UiRobot 2019.10.2 registered as a service within an AWS environment.
The experience below is the same when we were running 2018.3 and testing 2019.10 of both Orchestrator and Robot.
- Take a full screen screenshot
- Record the resolution of the primary screen
Out of box, assuming Robot is of type “Unattended” and credentials have been provided, the Robot should be able to connect to a machine/host; by default this will be using the Console which will take over any active sessions of that user kicking the original user off the active session.
Switching the Robot configuration from Console:true to Console:false, the job will fail if the Robot’s user is not part of a group that allows Remote Desktop Sessions, by default this is the local
Remote Desktop Users groups.
Could not start executor. Rdp connection failed: Message: The connection transport layer failed., Last error: 131085
Adding the user into the Remote Desktop Users group, the process will complete successfully.
Starting a RDP session from my own laptop with a native resolution of 1600x900* and the Robot still configured as Test2/3 (Resolution set to 1900x1200, Console:false). Session is Full sized (not full screen)
*I’m using RDCM, so the local screen resolution is a bit smaller at 1600x823 when at full screen
The process runs successfully using the existing session concurrently so I could ‘watch’ it and it used the resolution defined by the initial client/session.
Same session from Test 4, but this time I’m minimizing the RDP session running a process, bring the RDP session back up and running the process again, followed by disconnecting my laptop session and running the same process.
While minimized the following exception was thrown, followed by 2 successful job when not minimized then disconnected.
Info: Object reference not set to an instance of an object.
Continuation of Test 5, this time I added
RemoteDesktop_SuppressWhenMinimized into my laptop’s registry and minimized the RDP session.
Set Robot back to Console:true, removed
Users local group from the
Allow log on locally policy.
Logon failure: the user has not been granted the requested logon type at this computer. (Exception from HRESULT: 0x80070569)