Login Agent and AA Spying.

[NeilPannett]

Hi all, Hoping someone can assist with something that we're struggling to solve for. Our current set-up has our resource VMs activated via RDP (currently Citrix, but we've tried others), and this works okay (albeit with the limitations that come with that) - however we're moving towards login agent to activate the resource machines. We have login agent installed, and it works well in terms of activating the machines and connecting them to BP, however whenever we try to run a process that includes any AA spied elements (which work fine with the RDP connection set-up), they terminate and report that the element could not be found. We also witness the exact same result if we have an RDP connection that is minimized, which leads me to suspect that the underlying issue relates to screen resolution settings. When we connect via RDP, screen resolution is dictated by the RDP session, but without this session pushing a config out to the resource VM, I'm not sure what resolution is used, or how I can even go about checking it. Has anyone faced similar issues when setting up login agent? Regards Neil Pannett

[John__Carter]

Hi Neil - RDP is not a virtualisation protocol that we recommend. There are a number of reasons, but the main one is that an RDP desktop is not persistent - when you close the RDP connection the remote desktop is disposed. The remote machine is still running, but it has no desktop. Processes that depend on the desktop (surface automation, global keys and clicks etc) will fail but processes that don't, (HTML, web services, API etc) will still run. Same goes for minimising the RDP window - this will affect processes depending on what the processes are doing. Worth talking to your BP architect and this is a useful introduction. https://portal.blueprism.com/system/files/product/productpublic/5.0/Blu…

[NeilPannett]

Hi John, Thanks for your reply. This is exactly why we are trying to move away from RDP and towards login Agent - however it seems that using login agent replicates the same issue that you've outlined (ie the remote machine connects, but apparently has no desktop). I don't know if this could be a set-up issue with the resource VMs? I have reached out to our client manager and architect - I await their replies.