Changing resource PC user via Login Agent?

[PatrickOttery1]

Hi all, We are able to use the login agent service and provided object to ensure our runtime resources are always logged in. I am trying to build a process that can change which user the resource PC is running as, by logging out, then logging back in as a different user. When I daisy chain these together in a control room schedule, I get a process termination, because things move too fast. If I add a wait using the environment general VBO (it has a code stage for thread.sleep) then the process will terminate because once the resource PC listener is terminated, then it can no longer execute anything. What I want to do is -Logout -Login as custom User  -Run process -Logout -Login as regular user. Has anyone managed to do this before? Has anyone form Blue Prism ever tried this? Regards, Patrick.

[DaveMorris]

What version of Blue Prism are you using? Various versions have gotten the Post Completion delay added to Schedules so that you can choose how many seconds Scheduler should wait after a task completes before it sends instructions for the next process to the runtime resource.

[PatrickOttery1]

Yeah, I've since found that in v6. Unfortunately, we're currently running v5.0.24 and won't complete our upgrade until later this year.

[John__Carter]

Patrick - the issue with daisy chaining in v5 is that the scheduler can't handle the 'handover' between the two instances of resource pc. The effect is that the scheduler can instruct the wrong instance, eg it tells the login agent instance to run a 'do work' process, and the process can never succeed because Windows hasn't started yet. And the catch 22 is that adding a wait stage to the login process won't work because resource pc it runs on will be closed down automatically an the process will terminate. Yes it is confusing and annoying. The v6 pause David mentions was introduced to combat this problem, but it's still not ideal because you have to guess how long is enough. Unfortunately for v5 users the only options are to use fixed-time schedules or to invent some 'master' process that uses the command line API to orchestrate the daisy chain.

[PatrickOttery1]

Hi John, We've managed to hack a "delay" in between steps by running a dummy process on another machine (in the pool to minimise resource inefficiency) that simply waits for a pre-determined period of time. It has the same limitation as the v6 pause, but it does the job in the short term. Command line API is probably the way to go down the track, but we don't have the technical resources to dedicate to this right now. Regards, Patrick.