Could not identify process owning the foreground window

[WaseerHaffajee]

Scenario:

BP is installed on 2 Virtual Machines. 1 is Application Server (AS) and the other is Runtime Resource (RR).

Runtime Resource is not logged into but has a windows task scheduler that runs on Virtual Machine START UP.

The task scheduler executes script below and brings up BP:

[Blue Prism Install Location]\automate.exe /resourcepc /public

Login Agent is used to login to the RR to execute a process.

This ONLY works when the process being executed is ran in the background and fails when the process has to run in the foreground.

Issue:

The script executed by the task scheduler launches BP in the background using specified credentials (if provided).

On login via the Login Agent, it does not own the foreground process (because the task scheduler script owns it)

Implications:

You cannot run processes in the foreground i.e launching Internet Explorer and capturing details or Notepad.

Work around / Solution:

Run the task scheduler on Virtual Machine startup as per usual.

Run the same script on user login (login via login agent) as a startup task/program in the startup folder. However, you will have to kill the previous process launched by the task scheduler.

Script will live here and will be executed on login:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

Example commands for the script with 2 steps (variations also available in Power Shell):

taskkill /IM “Automate.exe” /F

[Blue Prism Install Location]\automate.exe /resourcepc /public

This will allow the user logged in via the login agent to own all the processes in the background and foreground.

Things to consider:

Task scheduler script is required to run on RR boot because it launches BP and makes the resource available to the AS and IC (interactive client) for the login agent to login

Why is this not a common issue? Because most Virtual Machines don’t shut down. If they do, someone physically logs in and manually launches BP (thereby launching it in the foreground)

Why did it happen to us? We’re running in a cloud environment and in order to optimize costs, Virtual Machines are turned on & off on a schedule so they don’t run 24 hours with no workloads

[Walter.Koller]

What is the advantage of using task scheduler to start BP as runtime resource?
It seems I didn't get the reasoning because the description above seems quite complicated.

We do as follows:
We have .bat file to run BP runtime resource on login in the startup folder you mentioned.
We send login request in BP Control to the resource.
LoginAgent receives the login request with credentials and does the log in.
.bat in startup folder is executed and BP runtime resource is available.

Task scheduler might be an option when Windows policies are not set maybe?

[WaseerHaffajee]

Hi Walter, 

What you have described is the second step that we run. The issue stems from the Runtime Resource being shut down or restarted.

If you restart your Runtime Resource and do nothing i.e. do not login. Check if you can use the login agent to login to your Runtime Resource. If your login agent is visible from Control room and is online, that means you are running a batch script on boot of the Runtime Resource. If this is the case, all your process will run in the background. You can test this by having a process that launches Internet explorer or notepad and see if it comes to the foreground.

However, after the restart, if your Runtime Resource does not come back online, then you’ve hit our scenario where we need to have the task scheduler running on Virtual Machine boot so that it appears online in BP Control. At this point, using the login agent will only allow the processes to run in the background & not foreground. Our solution as described, was to have the .bat file also run on start-up when using the login agent but first terminate the previous process launched by the task scheduler.

[Walter.Koller]

Hi, thanks for the explanation

When we restart our runtime resource we see this in Control:
- status: offline, because of the restart but only for short period of time and automatically moves to next status
- status: Logged out, meaning restart is finished and LoginAgent is waiting 
Then we send the Login process to this resource and:
- status: Idle, robot user successfully logged in to RR and is waiting
Processes now sent to this RR run in foreground.

We don't have any scripts on boot, only on logon.
Our resources are only offline when there is a problem. Normally they are either 'Logged out' or 'Idle'.

If the described procedure does not work for you please verify Windows Policies and LoginAgent service (and its configuration).