UI flows unattended issue

[Sumeth_002]

hi guys , 
 i  am having the problem as you guys above picture , i cant access the unattended flow and error message show ( " There is a user session on the target machine. Cannot execute unattended UI Flow")  . but i tested that flow in attend mode its run successfully for me . 
thank you . 

[HEATFreight]

@Anonymous have unattended flows ever worked for you?

Have attended flows ever worked for you?

Do you have a current license for unattended RPA?

Physical or virtual machine? If virtual, what hypervisor?

To be clear, you are getting the following error, right?

"There is a user session on the target machine. Cannot execute unattended UI Flow"

Your target machine is not configured to login automatically, right? Can you login to the target machine and manually run the flow –not even attended (cloud) or unattended (cloud)– but direct from PAD? Just open Power Automate Desktop and try to run the flow in question directly from the PAD console. What happens? Now sign out of all user accounts and try running unattended flow. But first, are you sure the correct machine/gateway is selected for the flow to run in? Have you configured it with correct credentials?

Do you have the Power Automate Desktop gateway application installed or do you have it configured as a PAD "machine" connection?

Can you provide the exact output from the action that triggers the error? (scrubbed for private info of course)

No one can help you beyond providing links to the documentation unless you provide some more details about your situation and the context of the error you're seeing.

[Anonymous]

Hi HEATFreight, thanks for the reply.

Both attended and unattended have worked and do sometimes work on this VM. It seems to be simply unreliable. I have placed my PAD flow in a loop so it will retry it like 10 times or until it runs successfully and oftentimes it makes it before the 10 are up.

Knowing that it works sometimes, I suppose most of your questions get answered but let me try anyway.

I believe it is a physical machine, I log into it via Remote Desktop Connection.

This is the exact error. I don't think it'll let me see more details:

I have been able to run the flow on that machine both from PAD directly as well as from Power Automate in attended mode (and again, unreliably as unattended as well).

To make sure nobody is signed in, I restart the machine and shortly after try to run the flow. Due to the aforementioned loop, it will then error out a couple of times until it finally is able to run successfully:

It honestly just feels like unreliability of the Microsoft product but who knows.

[HEATFreight]

Do you have physical access to the machine into which you are attempting to RDP? Does anyone else use that same machine besides yourself?

When you say 

I believe it is a physical machine, I log into it via Remote Desktop Connection.

that's the part you should stop doing!

Do not log into the machine via the remote desktop connection. Or if you need to login to verify the machine is running, then make sure to sign out of all user accounts on that machine before running the attended flow. Your remote desktop connection is blocking the "unattended" flow. The machine needs to be powered on but with no users signed in. No local users, no remote users, no users at all!

[Anonymous]

Of course not, I do not log in and then try to run the flow unattended, that would be dumb...

I'm saying that if and when I do want to check out the machine, I RDP into it. Then, to make sure nobody is logged in, I hit restart and a few minutes later (without logging back in obviously) I try to re-run my flow. I don't have physical access to it, but I'm pretty sure nobody else logs into it. 
I can say the unreliability is quite consistent, if that makes sense. Basically every time it will try to run it about 5-8 times, giving that error, until suddenly it manages to run it.

[HEATFreight]

Once it runs successfully, do further runs also fail several times before succeeding? Or does it ever "hit its stride" so to speak, and run successfully several times in a row?

Is the Windows operating system on that machine fully patched and updated to the most current version? What about the PAD gateway / PAD app, are they both fully updated? Or do you use a PAD "Machine connection" rather than PAD gateway to connect to the machine on which to run unattended flows? I must admit some ignorance with regard to running unattended flows, but I feel like there could be some error I might be able to spot if I had all the details, because I run a ton of attended flows and I'm fairly proficient at working with those. Unattended can't be that much different, I wouldn't think.

But yeah it does sound like you know what you are doing and that you've done the right things to make this work. My guess is that the error is wrong. Maybe there is no other account signed in, but something else is causing that error to be generated. Maybe some Windows system credential in triggering as if it's a signed-in user. 

Can you open a Command Prompt and run

net user

and provide the output?

Or press ⊞Win+X and click Computer Management, then >Local Users and Groups >Users. What all sign-in accounts do you see?

I suggest following these instructions to verify that you are the only user signing in on that machine.

If no clear reason for issue, you should spool up a Hyper-V virtual machine on a machine that you do have physical access to, and attempt to run the unattended flows in that VM instead.

If issue persists, who knows... But if issue goes away, then you are probably not the only user on that machine you're currently trying to use.

[Anonymous]

IT maintains that machine. I have to assume it is patched and updated. I'm using a very recent PAD, perhaps the most recent, I can't imagine that it would fail just because it is one or two minor versions behind.

The two outputs:

 

Might have to get together with IT to check out the Event Viewer:

And also to enable Hyper V.

I'm almost certain nobody else is using that machine, because (1) we're a tiny RPA team, (2) I run it in the morning in Europe and anybody who would try to use it would be in the US and I doubt they're logging in at 2 AM, (3) doesn't make sense that every time it consistently attempts to run a few times before finally succeeding, (4) there are many other posts out there claiming a similar issue, and (5) without wanting to muddy up the issue I am in parallel struggling with a similarly unreliable issue regarding a 'Could not attach to Edge' problem. Microsoft's official workaround for that problem is "make the action retry 20 times with 5 seconds in between". That workaround works half the time, the other half it attempts the 20 times and doesn't manage to attach and the entire flow fails. It just feels like an all-around unreliable product so I'm tempted to blame Microsoft rather than our infrastructure or code, but proving that feels harder than just putting up with the unreliability. 

[Gauravmahajan]

@Anonymous Thank you for providing the level of detail that you have. Everything you've mentioned or are doing seems to be right. Also, we have been running unattended flows for a while now on multiple machines and have never faced this error unless of course there's an actual user session of some sorts on the machine.

So just an out of the ordinary thought here: Could it be that the loop is causing hanging sessions? A couple of things I can suggest:

1. Increase your allocation of unattended licenses to the environment and then test

2. Make sure multiple flows are not trying to run on that machine at the same time 

I would also recommend trying a clean test (you mentioned you have already tried this but I would also include steps 3 and 4 in your tests):

1. I would recommend first removing the for-loops removed from your calling cloud flow

2. Restart the machine

3. Login to it and make sure that all the windows services have started correctly  (power automate services and the on-prem data gateway service) 

4. log out of the machine 

5. now run your unattended flow

That's the only thing at least I can think of.

Failing all this, you (ideally) or your IT should be able to create a support ticket through the Power Platform admin center

Thank you and hope this helps 

[HEATFreight]

Yeah it definitely looks possible that you have other accounts which could be trying to sign on to that system simultaneous to your attempted flow runs, but hard to verify without more info from IT.

I agree with @Gauravmahajan that simplifying the flow to avoid the loop and possible simultaneous flow runs might help you troubleshoot the issue. We use attended flows, so not exact same situation as you, but we had to implement a "flow running" flag to check flow activity before starting any new flows. We have a .txt file saved on the machine which is set to 0 if no flow is running, and before running any PAD flows we use a File System connector in Power Automate cloud flow to change that value to 1. Then after that flag has been set to 1, the cloud flow triggers the desktop flow, which also immediately writes 1 to flag .txt file, just in case by unlucky timing another flow has somehow set the flag back to 0 after the new flow's cloud trigger had already written 1. When the desktop flow finishes running, the last thing it does before exiting is reset the .txt file to 0 so that any other flows in queue can then run as well. Before each PAD flow runs, there is a loop running in the cloud flow to check for flag value of 0. Once value of 0 is returned, the loop exits. The cloud flow then sets the flag to 1 and launches the next PAD flow, which also writes 1... and so on.

This prevents the timeout error timer from starting until the flow is actually launching for real. As far as we can tell, Power Automate starts counting the PAD flow run time from the moment that Power Automate cloud flow triggers it, rather than from the moment the PAD flow actually begins running. Without the "flow running" flag, multiple flows can be queued up on the same machine such that the error timeout for a queued flow starts counting before the previous flow has finished running, thus causing cascades of unnecessary timeout errors.

The flag value logic completely resolves the issue of multiple queued PAD flows causing subsequent PAD flows to time out, well except in unlucky cases where multiple PAD flows are triggered nearly simultaneously. In that case, they may both see the same flag value of 0 before the other has had a chance to update the flag to 1. Thus whichever PAD flow happens to queue up later will still be at risk of timing out (we use short timeout durations so that no flow can get hung up and cause other flows to fail to run on time).

Anyway, I say all this because the idea that one flow run could interfere with another and present you with this error is intriguing! Does a flow run count as an active user session? But isn't PAD supposed to just deal with the incoming queue of flows and run them sequentially? Lot of stuff I don't understand here...

I think you should make the simplest possible PAD flow and launch it from the simplest possible cloud flow, and only test adding additional complexity only once you have the simple stuff working reliably.

Some additional thoughts:

Do you have any scripts or group policies that run periodically on that machine in the background?

Is it possible that there is some script or group policy which is executing some code that –while running– makes it appear to the Power Automate system as if a user is signed in?

Not a Windows expert, so unsure of whether the premise of this question is even reasonable or if I'm being totally nonsensical, but it seems to me that your machine is doing things you don't understand and don't have much visibility into and which could interfere with your flow runs. It seems to me that you don't have complete assurance that there are no other RDP sessions and that there are no other scripts or programs running on that machine which might produce an "active session" error. Seems to me that starting fresh in an environment with no possibility of unknown external interference from other users or background programs is your best bet, but guessing that's not an option for you. If you don't have such a system, Power Automate unattended RPA probably ain't for you. Not sure of better alternatives. All I know is you either need the system all to yourself, or you need someone to orchestrate the management of exactly who might be RDPing into that system at any given time and to manage the execution of cloud flows that trigger PAD flows to coordinate resource usage among all users. Your IT folks probably need to spin up more resources if this one seems to be having conflicts between users.

[Anonymous]

Hi @HEATFreight and @Gauravmahajan, these are all good tips and it's definitely possible that one of them could reveal something about the machine I am not aware of. However, it seems like a lot of work to tease out the root cause so for the next few days I am going to shift gears a bit. I will try to just get Selenium (Python) running directly on that VM and see if it's a smoother experience. I understand you miss out on a lot of advantages of PAD when you roll your own stuff but you also avoid a lot of headaches. If I'm unsuccessful with this new strategy I'm sure I'll be back to test out your tips. Thanks for the help!

[HEATFreight]

You ever figure it out?

I ended up building a sprawling canvas app to get rid of all the PAD flows I built to run browser automations on this janky legacy software we were stuck with, which tended to be slow and unreliable at times. Overall, a time-saver but still a massive boondoggle when things would fail for no apparent reason, where the usual culprit was probably the crappy website for said legacy software. Very difficult to track and correct errors from browser automations.

We went all-in on building a canvas app to fully replace the janky legacy software, and it's pretty sweet! Orders of magnitude improvement in runtime to complete the same tasks as well as in terms of development efficiency.

[Anonymous]

No, I ended up going that different route mentioned in my post so I never found out what the issue was with PAD.

[jhomeres]

this is still not functioning software.  I have paid for all the licenses needed to run automations in unattended mode and it still doesn't work.  i have followed all the BS resolution docs, read all the forums and still no solution to my problems.  i invested even more time than money into this software and it is an utter and complete waste of time.

[miguelE]

If the error keeps coming up, it means that you have at least one user logged in.

The best way I have found to run unattended flows it's to restart the machine, even if it is a VM (I only use VM to run my flows).
Signin out of your use account, won't work. I have tested it and each time I sign out, the Power Automate Cloud tells me that there is a user session on the target machine.

My advise it's to restart the machine after every time you access it with your account (you don't need to restart it after the Power Automate Cloud ran a flow).

Hope this helps!