Just curious, but why does the Picture-in-Picture functionality for UiPath require administrator rights to activate on its first run anyway? I am working in an office environment where the security is very strict and the administrator password cannot be given out no matter the circumstance.
External downloads are also heavily limited so virtual machines are not viable options to use as workarounds. Several clients at my workplace are currently troubled that they cannot run their desired automations while working on their desktops.
Hence, I was wondering whether it would be possible to activate PiP for end user machines without administrator rights, perhaps via UAC suppression or other means such as alteration of certain UiPath configurations. Any sort of answer or user mention would be appreciated, as this is somewhat urgent. Thank you!
Apologies for the late reply. The end users are still using the Attended bots that do not take so long to run. However there are other bots that take hours and that poses an inconvenience. Desktops at my workplace use a serverwide admin password, if that helps anything.
they need to execute the Process in PIP as there are some issues in the machine.
Not sure what you mean by this, sorry. Do you mean that there is no other way to activate PiP other than granting admin rights, or?
The difficulty in changing my bots to background processes is that my bots filters the Excel file contents based on specific criteria (for example, filtering May entries if current month is June) and highlights them with colour - these rely heavily on keyboard shortcuts in hardware events mode. When I use windows messages input mode, it stops at CTRL + Shift + L instead of executing the full sequence of shortcuts to filter based on above criteria, for example.
Also one of the bots interacts with Chrome elements by visiting a predefined site and clicking on its interface, so running PiP without administrator rights would be a perfect solution for my issue. However, if that is not possible, please do suggest an alternative - I am willing to try out various possibilities. Thank you.
Thank you for your reply, and sure. Regarding the installation method, we actually have both UiPathStudioSetup.exe and UiPathStudioCommunity.msi, though the latter is the one that is primarily used.
I am open to reinstalling UiPath if I can enable PiP during installation. However, from the article you provided, it is said that the command lines require administrator rights to run as well. I have tried keying “…\UiRobot.exe PiP --enable” into the command prompt before, but it returned a message as shown below:
System.UnauthorizedAccessException: Administrator rights are needed
at UiPath.CommandLine.CommandLineAppBootstrapper.DoAction_PiP(PiP argCommand)
Hence, I am not too sure how this would help with my problem - is there anything regarding the command lines that I should know about?
From what I understand now you do your installations by yourself?
Is it possible for you to ask an administrator at your company to do the installation and then enable PiP? (PiP only has to be enabled once)
It might also be usefull to distribute the UiPath client installation with the correct parameters to all the workstations in your environment under Admin credentials. I suggest you use the MSI-file in this case.
Does your environment has a workspacemanager?
If all of this is not possible, I dont think you can enable PiP unfortunately.
I am on the forum with an issue and question relevant to this topic. I too work in a high security environment, and ordinary users are running bots attended. We have a bot that worked flawlessly for months and broke a few days ago. (We suspect with a Windows Update.) Users get this UIPath dialog message:
“The process you’re trying to run was not tested for Picture in Picture. Running it in PiP may result in unexpected behaviors. Are you sure you want to start it?”
The operators click “Yes,” and the UIPath displays this (also a UIPath dialog):
“Picture in Picture is not enabled on your computer. Do you want us to enable it?”
Again they click “Yes.”
Now UAC demands a local admin password, which are operators do not have and must not have.
This never happened before. We suspect it’s due to a WSUS change, but we don’t know the cause. Has Windows Update broken some UIPath dependency? Or has a GPO reversed users’ right? The messages mask the cause,
Has anyone else had this happen? And how did you remedy it?
The best way to avoid the 2nd question is to centrally distribute the UiPath client to the workstations with the correct parameters and installation should be done with an account with admin privileges.