When in stalling the UiPath robot you can install it as user or service mode. (Details below)
Service Mode - recommended for unattended automation scenarios and large-scale platform deployments, and runs with the same rights as the user under which it is registered.
User Mode - recommended for attended automation scenarios, and runs under the user that installed it, having the exact rights as that particular user.
That being said. I have an unattended automation that has to run an application in admin mode. If you do this and try to run the bot while using service mode it cannot see the application. However if you run it in user mode it will work. We plan on having many more bots in the future. What is the real differences between user and service mode. Is it ok to run in User mode evnen with a large deployment?
The problem at scale and not running UiRobot as a service is you don’t have the UiRobot’s process listening for jobs unless you have a user logged in running the Robot Tray or Desktop.
What is the reason for not being able to run it as a service? Are the required permissions needed to be granted to the Robot’s user considered a security risk for you? It should have the permissions of the user you configured in Orchestrator so if those permissions are set appropriately to that user you shouldn’t have a problem.
So we run unattended bots and I currently have the user mode setup. It runs without issue and it does not matter if a user is logged in or not.
I don’t run as service in my current testing because the automation I just built requires the program to be ran in admin mode. When running as a service an elevated program runs in a different session ID from the service so they cannot interact with one another.
Try running a program like procmon.exe with a service account setup you will see what I am talking about.
I see what you mean; handling UAC, I wasn’t seeing an error after launching an application like procmon unless I had the UiRobot Tray open although it launched the application successfully.
UAC will popup
Error message: Cannot find the UI element corresponding to this selector:
Handling UAC (i.e. lowering it to the lowest of low settings), procmon.exe launches but UiRobot / process fails to detect given selector.
Configure procmon.exe to run as administrator,
Error message: The requested operation requires elevation. (Exception from HRESULT: 0x800702E4)
Configured UiRobot Service to run as a non-local service account.
Error message: Could not start executor. A required privilege is not held by the client. (Exception from HRESULT: 0x80070522)
So far the only way I’ve found around it is to Disable “User Account Control: Run all administrators in Admin Approval Mode”.
I should have mentioned that it launches every time it’s when you try to interact that you have issues. So I can use the user mode as a simple fix, I just wanted to make sure that would not cause issues in the future when we get more bots.
@loginerror@Pablito - Any chance you could seek out some feedback internally on best practices here in the cases where an application is required to run in an elevated admin mode and how that could be handled with unattended robots? (Ideally minimizing the security compromises)
Hi @codemonkee & @LeftBrainCo!
Let me try to explain how User Mode & Service Mode are different:
User Mode - All the Robot’s components(Service, Executor, Tray) live on the user’s session and run with current user’s permissions. Also, the Service is not started automatically. It’s started whenever you first open the Tray and it’s using the same authorization as the Tray. When you click to start a process, the Tray goes to the Service and the Service spawns an Executor (with the same permissions as the Service) and instructs it to execute the process. So, as you see: the Executor will run with the same permissions as the Tray. I think that’s why you (@codemonkee) could access resources that require elevation. The bad part about the User Mode is that it cannot create User Sessions (cannot log in) thus it can’t really be used in unattended. You have to be logged in on that Machine before being able to start a process from Orchestrator.
Service Mode - For this setup, the Robot Service is running as a Windows Service in Session 0 under the Local System user. It always runs and it always keeps the connection with Orchestrator open. Whenever Orchestrator says a process needs to run, the Service creates a new Windows Session for the User (set up in Orchestrator’s Robot) and in that Session, it spawns the Executor with normal user rights. From unattended we don’t and we’ll never support running processes with elevated rights. It’s too big of a security risk. If Orchestrator gets compromised, it means the attacker would also have admin access to all the machines connected to it.
@codemonkee, for your problem I don’t have an out of the box solution. But there may be others that managed to find a solution for it.
So I keep hearing you cannot run this unattended, but it works in my environment unattended on a vm that host our bot server. Nobody is logged into that machine and it’s working from orchestrator.
Im checking with our vm manager to see if they set something up so it could do this.
This will work if you leave the VM with a user logged in and then disconnect.
It works if your user is logged in on a VM (this is different from being connected to a VM). But if you were to log the user out from the machine and then disconnect, it will not work.
Grant a specific domain [robot] account to the local administrator group of a single robot host machine.
Disable “User Account Control: Run all administrators in Admin Approval Mode”.
Although I wouldn’t want to disable security in such as way; this approach would not be as sever as you suggest, would you agree with that? (though I do understand that it wouldn’t be support, purely from a technical interest and not having a Windows background).
ppr
rohith.prabhu
supermanPunch
Yoichi
Veera_Raj
Lak_Ui
Raina_Ocean_Sanjay
Kakooza-Allan-Klaus
gokul1904
bromanen